L_tmpnam macro

[Bob Nelson]

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

[Bob Nelson]

Bob Nelson wrote:

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?
[...]

My botch: ``s/7.7.4/7.9.4/''.

[Keith Thompson]

Bob Nelson <bn*****@nelsonbe.comwrites:

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.

I presume it was deliberate. The uppercase 'L' partially follows the
convention of uppercase macro names. The lowercase "tmpnam" refers to
the tmpnam() function.

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

No, here's another one:

#define the_answer 42

But seriously, C99's <stdbool.hhas macros "false", "true", and
"__bool_true_false_are_defined". Those are the only ones I can think
of. If you're more interested in the answer than I am 8-)}, you can
always look through the standard for other examples.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Bob Nelson wrote:

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

In C89 there's also:
offsetof
stdin
stdout
stderr
assert
errno
va_start
va_arg
va_copy

C99 has more.

--
pete

[Richard Bos]

pete <pf*****@mindspring.comwrote:

Bob Nelson wrote:

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

In C89 there's also:
offsetof
stdin
stdout
stderr
assert
errno
va_start
va_arg
va_copy

None of those expand to an integral _constant_ expression.

Richard

[Richard Heathfield]

pete said:

Bob Nelson wrote:

>Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

Is it the only macro expanding to an integral constant expression that
has lowercase characters in the name?

In C89 there's also:
offsetof
stdin

That doesn't look like any kind of integral constant expression to me.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Tobin]

In article <48*****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

>In C89 there's also:
offsetof
stdin
stdout
stderr
assert
errno
va_start
va_arg
va_copy

>None of those expand to an integral _constant_ expression.

offsetof does.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[pete]

Richard Tobin wrote:

In article <48*****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:

>>>Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

>>In C89 there's also:
offsetof
stdin
stdout
stderr
assert
errno
va_start
va_arg
va_copy

>None of those expand to an integral _constant_ expression.

Oops!

>
offsetof does.

--
pete

[Bob Nelson]

Keith Thompson wrote:

Bob Nelson <bn*****@nelsonbe.comwrites:

>Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.

I presume it was deliberate. The uppercase 'L' partially follows the
convention of uppercase macro names. The lowercase "tmpnam" refers to
the tmpnam() function.

And what of ``fopen_MAX'' where the lowercase ``fopen'' refers to the
fopen() function?

Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
convention not used with ``L_TMPNAM''?

(I think that ``L_tmpnam'' is singular as the only macro defined by the
language using mixed case.)

[Keith Thompson]

Bob Nelson <bn*****@nelsonbe.comwrites:

Keith Thompson wrote:

>Bob Nelson <bn*****@nelsonbe.comwrites:

>>Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.

I presume it was deliberate. The uppercase 'L' partially follows the
convention of uppercase macro names. The lowercase "tmpnam" refers to
the tmpnam() function.

And what of ``fopen_MAX'' where the lowercase ``fopen'' refers to the
fopen() function?

Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
convention not used with ``L_TMPNAM''?

Because the C standard is not an absolutely coherent document
describing a perfect language designed by superhumans. The language
was designed by very smart people (mostly one very smart person) who
make mistakes. Parts of the library were designed by different people
in different places, who didn't necessarily consult with each other.
The standard committee had the job of tying all this together into a
single document that everyone could agree on.

It's remarkable that it's as consistent and coherent as it is.

(I think that ``L_tmpnam'' is singular as the only macro defined by the
language using mixed case.)

Nope.

C99's <complex.hhas _Complex_I, and optionally _Imaginary_I.

C99's <inttypes.hdefines a large number of macros for format
specifiers that use mixed case (e.g., PRIdMAX to print an intmax_t
value in decimal).

I found these simply by looking at the beginning of each subsection of
section 7 of the standard (or rather, of the latest draft, available
at <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bob Nelson]

Keith Thompson wrote:

Bob Nelson <bn*****@nelsonbe.comwrites:

>Keith Thompson wrote:

>>Bob Nelson <bn*****@nelsonbe.comwrites:
Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by
a deliberate design decision?

You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.

I presume it was deliberate. The uppercase 'L' partially follows the
convention of uppercase macro names. The lowercase "tmpnam" refers to
the tmpnam() function.

And what of ``fopen_MAX'' where the lowercase ``fopen'' refers to the
fopen() function?

Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
convention not used with ``L_TMPNAM''?

Because the C standard is not an absolutely coherent document
describing a perfect language designed by superhumans. The language
was designed by very smart people (mostly one very smart person) who
make mistakes. Parts of the library were designed by different people
in different places, who didn't necessarily consult with each other.
The standard committee had the job of tying all this together into a
single document that everyone could agree on.

It's remarkable that it's as consistent and coherent as it is.

Yes indeed, as Dennis Richie stated: ``C is quirky, flawed and an enormous
success.'' Although I don't think it necessarily takes ``superhuman''
designers to be consistent in the naming style of macros, a dose of
pedantry could have helped in this regard. :-)

>(I think that ``L_tmpnam'' is singular as the only macro defined by the
language using mixed case.)

Nope.

C99's <complex.hhas _Complex_I, and optionally _Imaginary_I.

C99's <inttypes.hdefines a large number of macros for format
specifiers that use mixed case (e.g., PRIdMAX to print an intmax_t
value in decimal).

After reviewing both the C99 draft and ISO/IEC 9899:1990, the statement can
be modified as follow (modulo something I overlooked in my reading):

I think that ``L_tmpnam'' is the only macro defined by the language using
mixed case AND expanding to an integral constant.

[Keith Thompson]

Bob Nelson <bn*****@nelsonbe.comwrites:

Keith Thompson wrote:

>Bob Nelson <bn*****@nelsonbe.comwrites:

[...]

>>Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
convention not used with ``L_TMPNAM''?

Because the C standard is not an absolutely coherent document
describing a perfect language designed by superhumans. The language
was designed by very smart people (mostly one very smart person) who
make mistakes. Parts of the library were designed by different people
in different places, who didn't necessarily consult with each other.
The standard committee had the job of tying all this together into a
single document that everyone could agree on.

It's remarkable that it's as consistent and coherent as it is.

Yes indeed, as Dennis Richie stated: ``C is quirky, flawed and an enormous
success.'' Although I don't think it necessarily takes ``superhuman''
designers to be consistent in the naming style of macros, a dose of
pedantry could have helped in this regard. :-)

The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Serve Lau]

"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...

The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

Since it wasnt standardized yet changing the name would not break existing
code anymore than if they took a different name from another library. On top
of that it would only break if the name was defined in a standard header and
the final standard did not have this name. If they used their own header
there would be no problem so I dont think breaking code was the issue here,
just miscommunication or an oversight or something. No biggie anyway

[Eric Sosman]

Serve Lau wrote:

>
"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...

>The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

Since it wasnt standardized yet changing the name would not break
existing code anymore than if they took a different name from another
library. [...]

Um, er, WHAT??!

Are you claiming that no C code existed before 1989?
That ANSI decided to write a standard for a language that
had not yet been used, or had been used only for throwaway
programs of no importance?

L_tmpnam -- and printf, and gets, and int, and ...
are older than any C language standard, and were in use
long before a standard appeared on the scene.

(Something about this reminds me of the story of the
guy who tripped and fell heavily next to a seismometer,
causing a devastating earthquake in East Berzerkistan. Or
the story of the city slicker on his first visit to a hog
farm, watching the pigs being slopped and remarking "No
wonder they're called `pigs'.")

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Richard Tobin]

In article <b6***************************@cache3.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:

>The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

>Since it wasnt standardized yet changing the name would not break existing
code anymore than if they took a different name from another library.

You might as well say that as C wasn't standardised yet, changing it
to be Fortran would not have broken any existing programs.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[Serve Lau]

"Eric Sosman" <es*****@ieee-dot-org.invalidschreef in bericht
news:-8******************************@comcast.com...

Serve Lau wrote:

>>
"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...

>>The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

Since it wasnt standardized yet changing the name would not break
existing code anymore than if they took a different name from another
library. [...]

Um, er, WHAT??!

Are you claiming that no C code existed before 1989?
That ANSI decided to write a standard for a language that
had not yet been used, or had been used only for throwaway
programs of no importance?

of course not, I meant they took a name (L_tmpnam) from a library and
standardised that. You cant tell me there was no other codebase at the time
using a different name. Breaking code should not have been the issue here.
Actually, why is it such a bad thing that an added macro would break
existing code, its about a compile time issue.
Suppose they named it TMPNAM_MAX and the L_tmpnam code broke because the
name doesnt exist anymore. You switch to the new compiler, your code doesnt
compile anymore, you check why and find out about the new name. You check to
see what it expands to see if it could cause problems, recompile and
test....shouldnt we all expect some kinds of problems when switching to a
new compiler?

[Keith Thompson]

"Serve Lau" <ni***@qinqin.comwrites:

"Eric Sosman" <es*****@ieee-dot-org.invalidschreef in bericht
news:-8******************************@comcast.com...

>Serve Lau wrote:

>>>
"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...
The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

Since it wasnt standardized yet changing the name would not break
existing code anymore than if they took a different name from
another library. [...]

Um, er, WHAT??!

Are you claiming that no C code existed before 1989?
That ANSI decided to write a standard for a language that
had not yet been used, or had been used only for throwaway
programs of no importance?

of course not, I meant they took a name (L_tmpnam) from a library and
standardised that. You cant tell me there was no other codebase at the
time using a different name.

Why not? I don't know the detailed history, but it seems plausible
that somebody came up with the names "tmpnam" and "L_tmpnam", and that
by the type the language was standardized, nobody else had happened to
implement the same functionality using different names.

Breaking code should not have been the
issue here. Actually, why is it such a bad thing that an added macro
would break existing code, its about a compile time issue.
Suppose they named it TMPNAM_MAX and the L_tmpnam code broke because
the name doesnt exist anymore. You switch to the new compiler, your
code doesnt compile anymore, you check why and find out about the new
name. You check to see what it expands to see if it could cause
problems, recompile and test....shouldnt we all expect some kinds of
problems when switching to a new compiler?

Not if both compilers conform to the standard, but of course there was
no standard at the time.

So the committee had a choice in this case: break some existing code,
or break no existing code. The advantage of the former approach would
have been that they could change the identifier "L_tmpnam" to, um,
something else.

It's not the prettiest thing in the language, but I just can't get too
worked up about it. I can certainly understand their decision to
leave it alone rather than changing it for no good reason.

Does the name "L_tmpnam" really bother you that much?

Of course they could have gone through and cleaned up the entire
library (for someone's concept of "clean"), but that would have broken
virtually all existing code.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Serve Lau wrote:

>
"Eric Sosman" <es*****@ieee-dot-org.invalidschreef in bericht
news:-8******************************@comcast.com...

>Serve Lau wrote:

>>>
"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...
The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

Since it wasnt standardized yet changing the name would not break
existing code anymore than if they took a different name from another
library. [...]

Um, er, WHAT??!

Are you claiming that no C code existed before 1989?
That ANSI decided to write a standard for a language that
had not yet been used, or had been used only for throwaway
programs of no importance?

of course not, I meant they took a name (L_tmpnam) from a library and
standardised that. You cant tell me there was no other codebase at the
time using a different name. Breaking code should not have been the
issue here. Actually, why is it such a bad thing that an added macro
would break existing code, its about a compile time issue.
Suppose they named it TMPNAM_MAX and the L_tmpnam code broke because the
name doesnt exist anymore. You switch to the new compiler, your code
doesnt compile anymore, you check why and find out about the new name.
You check to see what it expands to see if it could cause problems,
recompile and test....shouldnt we all expect some kinds of problems when
switching to a new compiler?

The tail wags the dog. In the words of the Rationale:
"Existing code is important, existing implementations are not."
That is, the programmer should not work harder to adapt his
already-written, already-debugged, already-shipping-and-
configuration-controlled code to the whims of a new Standard,
but the Standard should bend over backwards to accommodate
the existing body of code.

Also from the Rationale, "The original X3J11 charter
clearly mandated /codifying common existing practice/," which
means the Committee had a to clear a rather high justification
hurdle whenever it proposed to adopt something different or
make an incompatible change. Somebody's dislike for a macro's
spelling just isn't enough impetus to lift a change proposal
over the bar against gratuitous meddling.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Serve Lau]

"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...

"Serve Lau" <ni***@qinqin.comwrites:
Does the name "L_tmpnam" really bother you that much?

No I dont care at all :) Too much time on my hands, will be over tomorrow :(