search

nothings / stb

stb single-file public domain libraries for C/C++
https://twitter.com/nothings
Other
27.11k stars 7.72k forks source link

reserved identifier violation #277

Closed elfring closed 8 years ago

elfring commented 8 years ago

I would like to point out that identifiers like "stb__perlin_randtab" and "stbi__context" do eventually not fit to the expected naming convention of the C++ language standard. Would you like to adjust your selection for unique names?

zao commented 8 years ago

Is there an actual collision you've observed in the wild or an implementation that uses similar prefixes that is at risk of collision? Some things are more important to conform to than others, and the extremely wide "double underspaces are forbidden" rule is one that really shouldn't exist in the form it currently does.

If you're out to burn months of programmer attention by reporting non-issues to issue trackers, can't you at least pick an issue that has a chance of actually mattering?

You might want to adjust your issue filing script to realize that some libraries are in C, and as such, doesn't even HAVE the rule you cite. See C99 7.1.3.

elfring commented 8 years ago

How do you think about to avoid that this software depends on undefined behaviour?

zao commented 8 years ago

In C, it does not use any reserved identifiers. In C++, that's the problem of the integrator if they decide to compile the TU with STB_IMAGE_IMPLEMENTATION and STB_PERLIN_IMPLEMENTATION as C++ instead of C. If you're not familiar with the stb libraries, you define the implementation macro in a single TU, which traditionally is built as a C file as that's what it is.

It's a non-problem as no C reserved identifiers are used, and in C++, if you call this "undefined behaviour" worth caring about, you need a real hobby. No-one is going to summon nasal daemons from the presence of an identifier that has two underscores in the middle.

Looking at your previous carpet bombing issues, I see that you're not likely to accept any reasoning. I'm just providing an argument for with which to rapidly close this pointless issue.

If you're reading this and take anything away from it, please stop lawyering things that do not matter. Grow up, realize you're wasting time of people doing actual good, and do some good yourself.

nothings commented 8 years ago

Would you like to adjust your selection for unique names?

No. As noted elsewhere, I am fully aware of the theoretical issue (https://github.com/nothings/stb/blob/master/docs/stb_howto.txt#L113). If this becomes a practical rather than theoretical issue, it can be addressed when that happens.

How do you think about to avoid that this software depends on undefined behaviour?

I think compilers that exploit undefined behavior for optimization are broken, as are standards that encourage this; the de facto standard has historically been otherwise, and we shouldn't encourage compilers to deviate from the de facto standard. (Indeed, At least one stb library is explicitly reliant on disabling strict-aliasing optimizations, i.e. it 'depends on undefined behavior'.)

elfring commented 8 years ago

… If this becomes a practical rather than theoretical issue, …

  • Do you care if your source code tampers with the reserved C++ name space?
  • Is it harder to achieve consensus on the consequences for the term "undefined behaviour"?
RichardGale commented 8 years ago

My app shipped successfully in all app stores so I for one don't care about the odd underscore.

rygorous commented 8 years ago

Please, everyone, this isn't a forum, it's a bug tracker. Keep it focused and don't trade insults.

As Lars correctly pointed out, this is a C++ restriction and the stb libs are written in C. C++ compatibility is generally maintained but is not a must, and some of the libs in this repository already don't work in C++, e.g. stretchy buffer.

If this ever causes anyone actual problems, it will get changed. As-is, this ranks at about the same level of importance as compatibility issues with platforms having one's complement integers or non-8-bit-bytes, namely: entirely hypothetical for the users of these libraries (so far).

As a general rule, the stb libraries (and their existing users) care a lot more about practical compatibility with actual compilers (including several embedded or old compilers that diverge from the C/C++ standards in various ways) than they care about language lawyering. On Apr 7, 2016 04:06, "Richard Gale" notifications@github.com wrote:

My app shipped successfully in all app stores so I for one don't care about the odd underscore.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/nothings/stb/issues/277#issuecomment-206818798

nothings commented 8 years ago

Actually all stb-prefixed libraries are supposed to be fully C++ compatible.

Do you care if your source code tampers with the reserved C++ name space?

No. All further questions you ask along these lines will be answered with "no", so you can stop asking them.

Is it harder to achieve consensus on the consequences for the term "undefined behaviour"?

I have the consensus of my peers and my users.

http://blog.regehr.org/archives/1180 http://robertoconcerto.blogspot.com/2010/10/strict-aliasing.html https://lkml.org/lkml/2003/2/26/158

I don't care about the opinions of language lawyers, compiler writers, or standards authors.