Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In scheduler/client.c 'for (char *start = ...' is only allowed in C99 mode #1000

Closed
jsmeix opened this issue Jul 2, 2024 · 4 comments · Fixed by #1004
Closed

In scheduler/client.c 'for (char *start = ...' is only allowed in C99 mode #1000

jsmeix opened this issue Jul 2, 2024 · 4 comments · Fixed by #1004
Assignees

Comments

@jsmeix
Copy link

jsmeix commented Jul 2, 2024

Since
a7eda84
from #974
there are now two 'for' loop initial declarations

for (char *start = ...

which are only allowed in C99 mode.
When not in C99 mode one gets a compiler

error: 'for' loop initial declarations are only allowed in C99 mode

Has C99 mode become mandatory to compile CUPS?

I ask because when I compile CUPS 2.4.10
in a SUSE SLES12 SP5 build environment,
I get the above compiler error.

@jsmeix
Copy link
Author

jsmeix commented Jul 2, 2024

avoid_C99_mode_for_loop_initial_declarations.txt

I use this patch (uploaded here with *.txt file name)
to compile CUPS 2.4.10 in a SUSE SLES12 SP5 build environment.

@michaelrsweet
Copy link
Member

No, prior to CUPS 2.5 we don't require C99 support. We should update this code to not depend on loop variable declarations...

@zdohnal
Copy link
Member

zdohnal commented Jul 8, 2024

@jsmeix Thank you for the patch! I saw you double-reference the pointer - IIUC it is not correct, can you check if the patch in the attached PR works for you? I've used the existing ptr instead, so it should save memory.

@zdohnal zdohnal closed this as completed in 56ac0b4 Jul 8, 2024
zdohnal added a commit that referenced this issue Jul 8, 2024
Do not use C99-only construct (fixes #1000)
@jsmeix
Copy link
Author

jsmeix commented Jul 8, 2024

@zdohnal
thank you!

Yes, my patch is faulty.
But as long as it compiles all must be "allright" ;-) cf.
https://libquotes.com/linus-torvalds/quote/lbl0v5c

I replaced my patch with your upstream fix in
a2b8872

FYI:
The actual reason for my fault was "focus of mind".
At that time I was not at all interested in that new issue.
It got in my way while trying to get something different done.
So I only wanted to get that annoyance somehow out of my way.
Or simply put: Mental stack overflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants