Why C is really a bad programming language

Nobody · Aug 18, 2009

Yes, but I thought that the Y2038 problem was specific to Unix-like
systems. I don't claim enough Windows expertise to be certain of that.

Windows also uses 1970-1-1 as its epoch (although if you're writing
portable code, you won't be making any assumptions about the epoch).

I thought it used 1980, but it turns out that's just for the FAT
filesystem.

However, time_t has been 64-bit since Visual C++ 2005.

I suspect that the Unix folk are relying upon most 32-bit platforms
becoming obsolete before 2038.

Nobody · Aug 18, 2009

I don't think a struct argument would be a problem; all of the ABIs I'm
familiar with pass a struct as if its members were individual arguments.

Odd; all of the ones I've seen preserve the struct layout on the stack, so
that you can do e.g.:

void foo(struct bar b)
{
struct bar *p = &b;
...
}

Coercing a 64-bit time_t into a 32-bit int or long would hopefully cause
a compiler warning, regardless of the underlying ABI.

Right; but that doesn't fix your code for you.

The main problem is that C doesn't make it easy to write generic
arithmetic functions. If you want to write a library which deals with
integer data, you either have to pick a specific type, or write separate
versions for each type, or use "long long" throughout (and suffer the
performance and portability penalties), or use some kind of macro
processor. And none of those works if it's a third party binary library
which doesn't support anything wider than an "int".

In C++, you can just use a template, parameterised upon the type.

There's also the issue of printf/scanf specifiers for platform-specific
numeric types.

Nick Keighley · Aug 18, 2009

> > On 31 July, 07:49, Thomas Matthews
> >
> > > At one company I worked with, they couldn't upgrade to the latest
> > > VB without rewriting all of their existing code.
> >
> > this isn't confined to Basic, I have a C++ application that faces the
> > same problem.
>
> At least the C++ developers had the option of coding to
> a standard, so that they could upgrade in future without
> breaking.

it was coded to the standard. It did break.

There have been a few incompatible C++ standards around.

I'm sure VB is worse but C++ does have its problems

Phil Carmody · Aug 18, 2009

What's the problem? Apart from the errors in propagating them which
you yourself introduced.

Talk with Phil about that.

You do have a problem with precision, don't you?

Phil

James Kuyper · Aug 18, 2009

Phil said:
What's the problem? Apart from the errors in propagating them which
you yourself introduced.

I didn't introduce those errors, they were introduced by my newsreader;
but it's not the fault of the newsreader, either. Use of non-standard
quoting characters carries a price, and part of that price is that they
won't always be recognized as quoting characters in all contexts where
you'd like them to be.

You do have a problem with precision, don't you?

I identified the source of the non-standard quoting characters with
sufficient precision for the context. (e-mail address removed) was the
most recently cited Phil, and the one I was actually referring to.

Guest · Aug 18, 2009

|>|> (e-mail address removed) writes:
|>|>>>
|>|>>> C does not mandate the use of 32-bit integers for time_t.
|>|>>> This is truly an implementation issue, and the fix is so easy that
|>|>>> implementors have no excuse for not fixing the problem right now.
|>|>>
|>|>> Binary compatibility with existing code seems like a pretty good excuse
|>|>> to me.
|>|>
|>|> Precisely which binary interfaces did you have in mind?
|>|
|>| One is the binary interface between a program and a dynamically linked
|>| C library, like say the time function.
|>
|> C does not have binary interfaces.
|
| Yes it does. Units of a C program can be separately translated, and
| put together using linkage, which is a standard-defined concept. This linkage
| depends on assumptions like that the units agree about the representation of
| the types involved in that linkage.

Please cite chapter and verse for a binary interface definition in the C
standard.

Again, C does not have binary interfaces. C has symbolically expressed
interfaces that are reduced to some binary form by compilation and linkage.
These forms vary by architecture. C defines some minimum values for some
things, that has the effect of requiring a minimum binary definition. The
ABI defines the binary interface. Some architectures have more than one.

Guest · Aug 18, 2009

| Good lord; would whoever that is please use the standard quote character
| (i.e. '>') so we can figure out who said what?

What standards document specifieds '>'?

I have no trouble figuring out who said what as long as people use just
ONE character, although I know of no standard that limits it to one.
I've been using '|' for years with no trouble until this thread.

Maybe it's better to just remove the excess quoting. This is Usenet.
People can go back to see the whole previous postings. Quoting is for
identifying what specific point is being responded to. Double quoting
is only useful when the responded quote is not easy to understand out
of its context.

| You can get pretty close with any ABI that specifies passing arguments
| and return values in registers and where the underlying CPU will
| sign-extend an undersized argument. Of course, that will stop working
| when you need to represent times past Y2.038K (assuming the usual
| 32-vs-64-bit time_t problem), but that's an insolvable problem.

It will fail for any remaining 32 bit systems. A cross-size compatible
ABI would be useful for the transition period before the greater size is
actually needed. Once the greater size is actually needed, then we do
need to be using that size. And we'll need a 64-bit time_t by the time
any calculations that work with it to calculate times in the future are
being done that far in the future. Non-system programs, such as doing
a mortgage table calculation, should be done independent of system time
standards.

| That won't work for the specific case of using a (time_t *), but I can't
| recall having ever seen that in real code.

And not all architectures can use the register effect as suggested, either.
We need to transition to a 64-bit environment, and where that is not an
option, transition to a psuedo-64-bit one (e.g. an ABI that defines time_t
and off_t and maybe a few other things to be 64 bits, likely implemented
with simulated 64-bit).

Guest · Aug 18, 2009

| Yes, I was assuming a 64-bit (i.e. 64-bit GPR) system. A 32-bit system
| with a 64-bit time_t is going to be much more difficult to make
| backwards-compatible, but such systems also seem to be rare in practice.

It's not that hard. Just don't use the disaster done for 64-bit file
offsets as an example. Requiring source code to be modified, even if
it is just to insert some new symbol definitions before header includes,
is not the way to go. The multi-lib approach works. A 2-way multi-lib
is used to transition from 32-bit ABI to 64-bit ABI. Add an intermediate
mixed 32/64-bit ABI where off_t and time_t are 64-bit, with void* and its
peers remaining at 32 bit. The 32-bit and 32/64-bit ABIs can run on old
32-bit-only machines. Programs compiled under the 32-bit ABI will be
linked to the 32-bit libs. Programs (no change to source as long as the
code was not originally size dependent) compiled under the 32/64-bit ABI
will be linked to the 32/64-bit libs. People can choose to run machines
as pure 32-bit or pure 32/64-bit or as 32-bit plus 32/64-bit multi-lib.
Then for 64-bit architectures, add a pure 64-bit lib and 3-way multi-lib.

|>> ... Of course, that will stop working
|>> when you need to represent times past Y2.038K (assuming the usual
|>> 32-vs-64-bit time_t problem), but that's an insolvable problem.
|>
|> Well, it's precisely that insolvable problem which is the point of this
|> discussion.
|
| I thought the problem being discussed was how to recompile libraries to
| support a 64-bit time_t without breaking apps that use a 32-bit time_t.

It's not insolvable. Clearly, an app using a 32-bit SIGNED time_t will
have a problem at 03:14:08 on 19 January 2038, or even before if it does
any future time calculations. UNSIGNED may be a temporary workaround by
trading off the ability to represent dates from Friday 13 December 1901
to Wednesday 31 December 1969 for the ability to represent dates from
Wednesday 20 January 2038 to Sunday 7 February 2106. But that is at best
just a hack with many lurking problems if code that is compiled to use
signed CPU instructions is involved.

Ultimately everything must move to at least a 64-bit time_t. Assuming
we are not all using 64-bit or larger architectures by the time it is
needed, the mixed size ABI (32/64) will work. The multi-lib idea for
running bot 32-bit and 32/64-bit (or 64-bit) apps on the same machine is
just pre-2038 transition strategy. It is not a post-2038 solution.

| Obviously those apps can never represent a time after Y2.038K; however,
| an app that only needs to represent times in the past, present, or near
| future would continue to work until near that time.

If they are coded for transparency in types, at least for the ones to be
increased in size, recompiling to a 32/64 bit ABI will work. Some apps
are badly coded and will have issues. But that's a programmer issue.

| Without a transition plan, though, one could not compile _new_ apps for
| the 64-bit time_t, which means those with _any_ legacy code they can't
| recompile would be prevented from switching over -- and all _new_ code
| would instantly become legacy code as well.

The legacy code with problems is the code that is 32 bit dependent in the
source itself. While defining time_t as a type was the way to avoid that
problem, some programmers still do stupid things. Correct code can just
be recompiled to which ABI is preferred (32/64 or pure 64).

Guest · Aug 18, 2009

| On Tue, 18 Aug 2009 02:51:39 +0000, James Kuyper wrote:
|
|>>> I would actually have expected that it's pretty common to use tools
|>>> other than C (like spreadsheets) and operating systems that are not
|>>> Unix-like (such as Windows) for such purposes,
|>>
|>> Well, Windows has time_t too!

|>
|> Yes, but I thought that the Y2038 problem was specific to Unix-like
|> systems. I don't claim enough Windows expertise to be certain of that.
|
| Windows also uses 1970-1-1 as its epoch (although if you're writing
| portable code, you won't be making any assumptions about the epoch).
|
| I thought it used 1980, but it turns out that's just for the FAT
| filesystem.
|
| However, time_t has been 64-bit since Visual C++ 2005.
|
| I suspect that the Unix folk are relying upon most 32-bit platforms
| becoming obsolete before 2038.

Don't assume too much. There are still 16-bit platforms around in very small
embedded controllers. I doubt your coffee maker needs to go beyond a 32-bit
platform even in 2040. But it will need to calculate time correctly, so a
mixed 32/64 bit ABI where time_t is 64 bits would be doable.

Guest · Aug 18, 2009

|>>
|>> Yes, but I thought that the Y2038 problem was specific to Unix-like
|>> systems. I don't claim enough Windows expertise to be certain of
|>> that.
|>
|> Windows also uses 1970-1-1 as its epoch (although if you're writing
|> portable code, you won't be making any assumptions about the epoch).
|
| The "epoch" is not the decision of the OS, but of the implementation.
| For example, Microsoft used 1/1/1970 as its "epoch" for Visual C++'s
| time_t, in all versions except one, where they used some completely
| different date (I forget exactly which date).

Indeed. I have used other epochs in an enhanced time/date library. It's
just a matter of defining things. And C didn't define interfacing to time_t
by other than the various functions that do it, so an implementation can use
the OS definition. Even if C had defined an epoch, all that would give us
is the ability to expect specific values when cast to an int or long. At
least we have a definition of the delta time.

jameskuyper · Aug 18, 2009

[email protected] said:
|>|> (e-mail address removed) writes:
|>|>>>
|>|>>> C does not mandate the use of 32-bit integers for time_t.
|>|>>> This is truly an implementation issue, and the fix is so easy that
|>|>>> implementors have no excuse for not fixing the problem right now.
|>|>>
|>|>> Binary compatibility with existing code seems like a pretty good excuse
|>|>> to me.
|>|>
|>|> Precisely which binary interfaces did you have in mind?

Why are you looking for a precise list of interfaces? Why do you
imagine that he does have, or should have, one or mores specific
binary interfaces in mind? Why should he have anything in mind other
than the fact that changing the size of a type that is passed through
a binary interface is generally problematic; and even more so if it's
a pointer to the type rather than the type itself?

|>| One is the binary interface between a program and a dynamically linked
|>| C library, like say the time function. ....
Again, C does not have binary interfaces.

There is a binary interface between the caller of the time functions
and the time functions themselves; that the interface is specified by
a platform-specific document rather than by the C standard is
irrelevant to the comment made above about binary compatibility, as is
the fact that it may be a very different interface on different
platforms.

All that matters is that such as change will probably render code
compiled for a 32-bit time_t incompatible with other code compiled for
a 64-bit time_t, if they communicate with each other or with the
standard library using time_t.

Elsewhere in this thread you've described features of some ABIs that
would allow passing time_t values as function arguments without loss
of value, but you haven't indicated how many ABIs you're aware of that
have those features; since registers at least 64-bits wide are one of
the requirements, such ABIs are certainly far from universal at this
time. In any event, those features won't help at all with pointers to
time_t, nor with aggregates containing time_t.

Guest · Aug 18, 2009

Guest · Aug 18, 2009

Guest · Aug 18, 2009

| On Sun, 16 Aug 2009 10:29:00 -0500, Stephen Sprunk wrote:
|
|>> Do you know of any ABI where modules which communicate with each other
|>> using time_t would remain binary compatible with each other if compiled
|>> by compilers with different ideas of the size of time_t?
|>
|> You can get pretty close with any ABI that specifies passing arguments
|> and return values in registers and where the underlying CPU will
|> sign-extend an undersized argument. Of course, that will stop working
|> when you need to represent times past Y2.038K (assuming the usual
|> 32-vs-64-bit time_t problem), but that's an insolvable problem.
|
| It also makes having a 64-bit time_t rather pointless. Either a 32-bit
| time_t is a problem or it isn't. If it is a problem, then you need a
| 64-bit time_t *everywhere*.

*everywhen* after any values will reference a time after 2038-01-19 03:14:07.

During the transition, when 32-bit still works, we need to move towards
using 64 bits for time_t because we know we will need it. And we know the
deadline although some needs will exist prior to that. Switching everything
over at the same instant is not practical. But we can do this switch even
on 32-bit machines.

|> That won't work for the specific case of using a (time_t *), but I can't
|> recall having ever seen that in real code.
|
| It won't work for a structure field either.
|
| The other problem with using a 64-bit time_t on a 32-bit system is code
| which coerces a time_t to int or long. Most of the issues have already
| been discovered in connection with using a 64-bit off_t on a 32-bit system.

The same kinds of issues can exist, of course. Best we not wait until 2038
to figure them out.

Beej Jorgensen · Aug 18, 2009

What standards document specifieds '>'?

Son-of-RFC 1036 says you "SHOULD" use ">", but admittedly that's not a
standards document.

Also, vim by default doesn't recognize | at the start of a line for
reformatting purposes (though this can be changed easily enough in the
"comments" variable). Other viewers might get confused, as well, but I
suspect practically it really doesn't matter that much.

-Beej

Guest · Aug 18, 2009

| Nobody wrote:
|> On Sun, 16 Aug 2009 10:29:00 -0500, Stephen Sprunk wrote:
|
| Please do not remove attribution lines. James Kuyper wrote the
| following section, not me.
|
|>>> Do you know of any ABI where modules which communicate with each other
|>>> using time_t would remain binary compatible with each other if compiled
|>>> by compilers with different ideas of the size of time_t?
|>>
|>> You can get pretty close with any ABI that specifies passing arguments
|>> and return values in registers and where the underlying CPU will
|>> sign-extend an undersized argument. Of course, that will stop working
|>> when you need to represent times past Y2.038K (assuming the usual
|>> 32-vs-64-bit time_t problem), but that's an insolvable problem.
|>
|> It also makes having a 64-bit time_t rather pointless. Either a 32-bit
|> time_t is a problem or it isn't. If it is a problem, then you need a
|> 64-bit time_t *everywhere*.
|
| _Existing_ code with a 32-bit time_t is going to eventually break;
| nothing can be done about that. The problem is that, without being able
| to transition to a 64-bit time_t, all _new_ code is also going to break,
| and a transition is infeasible in some cases if the two cannot coexist.

New code today can be made to keep time_t transparent. Then it can be
compiled into 32-bit ABI that works for a while, and either 32/64-bit ABI
or 64-bit ABI that works for the next 292 billion years.

| I don't think a struct argument would be a problem; all of the ABIs I'm
| familiar with pass a struct as if its members were individual arguments.

Depending on the order of the struct members, offsets can be an issue.
If time_t is first and the 2nd member needs 32-bit or less alignment,
such as another time_t (example: begin and end times for an interval).
This is still an issue. Are you expecting every argument on the call
stack to be spaced 64 bit apart?

| The problems _are_ similar to the transition of off_t from 32 to 64
| bits. Hopefully we have learned from that and figure out a better
| strategy; we also have a bit more time (no pun intended) to get it
| right. The sudden growth of disks (and files) from a few megs to a few
| gigs took a lot of folks by surprise, so it is no surprise that last-
| minute kludges proliferated; we all know exactly when Y2.038K is coming.

Yes, we need to learn from the mistakes of transitioning off_t. We should
have transitioned both together. But the scheme that was used for off_t
required definitions that would not imply time_t being changed.

| On POSIX systems, the best technical solution is actually fairly simple:
| up the library major version number and modify the headers at the same
| time. Old apps will continue to be linked with the old libraries, and
| new apps will be linked with the new libraries. Windows doesn't allow
| multiple versions of a given DLL to coexist, though, which is the root
| of the well-known "DLL Hell".

The multi-lib approach, where there is a dynamic linker for each lib-ABI,
would have done the job. It works for the transition of void* from 32-bit
to 64-bit. It would have worked for transitioning off_t. It can work for
the transitioning of time_t. I suggest including a 64-bit off_t in the
intermediate 32/64-bit ABI libs (so even if the 64 bit file offset defines
are not done, you get 64 bit file offsets anyway), since only new compiles
will be linking to this.

Guest · Aug 18, 2009

| The main problem is that C doesn't make it easy to write generic
| arithmetic functions. If you want to write a library which deals with
| integer data, you either have to pick a specific type, or write separate
| versions for each type, or use "long long" throughout (and suffer the
| performance and portability penalties), or use some kind of macro
| processor. And none of those works if it's a third party binary library
| which doesn't support anything wider than an "int".

Despite many C progammers hating them (I've been in one rather heated
"debate" over it), I do use macros a lot for stuff like this (and many
other things). Some extensions present in GCC and other compilers does
help. Here's one example which uses a couple extensions:

#define mx_inv_3x3(i,m) ({ \
__typeof__(**(m)) __dt__; \
(i)[0][0] = (m)[1][1]*(m)[2][2] - (m)[1][2]*(m)[2][1]; \
(i)[0][1] = (m)[0][2]*(m)[2][1] - (m)[0][1]*(m)[2][2]; \
(i)[0][2] = (m)[0][1]*(m)[1][2] - (m)[0][2]*(m)[1][1]; \
__dt__ = (m)[0][0]*(i)[0][0]+(m)[1][0]*(i)[0][1]+(m)[2][0]*(i)[0][2];\
if ( __dt__ != 0.0 ) { \
(i)[0][0] /= __dt__; \
(i)[0][1] /= __dt__; \
(i)[0][2] /= __dt__; \
(i)[1][0] = ((m)[1][2]*(m)[2][0]-(m)[1][0]*(m)[2][2]) / __dt__; \
(i)[1][1] = ((m)[0][0]*(m)[2][2]-(m)[0][2]*(m)[2][0]) / __dt__; \
(i)[1][2] = ((m)[0][2]*(m)[1][0]-(m)[0][0]*(m)[1][2]) / __dt__; \
(i)[2][0] = ((m)[1][0]*(m)[2][1]-(m)[1][1]*(m)[2][0]) / __dt__; \
(i)[2][1] = ((m)[0][1]*(m)[2][0]-(m)[0][0]*(m)[2][1]) / __dt__; \
(i)[2][2] = ((m)[0][0]*(m)[1][1]-(m)[0][1]*(m)[1][0]) / __dt__; \
} \
__dt__; \
})

It even allows mixing the types which would complicate the C++ templates.

Guest · Aug 18, 2009

| (e-mail address removed) wrote:
|> | (e-mail address removed) wrote:
|> |>> C does not mandate the use of 32-bit integers for time_t.
|> |>> This is truly an implementation issue, and the fix is so easy that
|> |>> implementors have no excuse for not fixing the problem right now.
|> |>
|> |> Binary compatibility with existing code seems like a pretty good excuse
|> |> to me.
|> |
|> | Sooner or later the binaries that it is incompatible with will have to
|> | be recompiled with a newer library if possible, or discarded if
|> | necessary. The sooner this happens, the better for everyone (except, of
|> | course, whoever it is that has to do the recompile or replace the
|> | discarded binary). As long as a backwards compatibility option is
|> | provided (it could even be the default, at least for the next decade or
|> | so), this shouldn't be a serious problem.
|>
|> It does not need to be recompiled. The system just needs to keep a legacy
|> library for the old ABI, and use a new library for a new ABI (ABI's might
|> differ in just a few things like size of time_t and off_t).
|
| Consider a function in one module which calls mktime() to get a time_t
| value, which it then passes to a function in another module, which
| passes that value to ctime(). The first module is compiled with the
| headers for the old version of the library, and for one reason or
| another it is not feasible or acceptable to recompile it with the
| headers for the new library. The other module is compiled with the
| headers for the new library. Since you've assured me that the first
| module won't need to be recompiled, I can link those two modules
| together to form a single program, without worrying about binary
| compatibility problems, despite the change in both the size and
| representation of time_t? I'm truly impressed - and also highly skeptical.

This is a "mixing ABIs" issue. You can describe this scenario for any 32
bit to 64 bit transition, including full pure 64-bit programs that try to
link to 32 bit modules. This is to be avoided. E.g. don't link together
different ABIs. If something cannot be recompiled, then it is stuck in the
ABI it was compiled in, and any linkage to it needs to also be in the same
ABI. A system can allow for multiple ABIs by having libraries for each (in
separate directories is the typical approach) with separately named dynamic
linkers to start things.

Guest · Aug 18, 2009

| On Sat, 15 Aug 2009 21:40:49 +0000, phil-news-nospam wrote:
|
|> FYI, the whole mess with 64 bit file offsets was done all wrong. It should
|> have simply been a new ABI that has a slightly different library name.
|> Keep both libraries where legacy binaries exist. All recompiles would by
|> default use the new ABI definitions.
|
| There are other problems with file offsets, e.g. fseek/ftell using "long"
| for the offset rather than off_t, passing file descriptors between
| processes, etc.

When are those going to be fixed?

Keith Thompson · Aug 18, 2009

| On POSIX systems, the best technical solution is actually fairly simple:
| up the library major version number and modify the headers at the same
| time. Old apps will continue to be linked with the old libraries, and
| new apps will be linked with the new libraries. Windows doesn't allow
| multiple versions of a given DLL to coexist, though, which is the root
| of the well-known "DLL Hell".

The multi-lib approach, where there is a dynamic linker for each lib-ABI,
would have done the job. It works for the transition of void* from 32-bit
to 64-bit. It would have worked for transitioning off_t. It can work for
the transitioning of time_t. I suggest including a 64-bit off_t in the
intermediate 32/64-bit ABI libs (so even if the 64 bit file offset defines
are not done, you get 64 bit file offsets anyway), since only new compiles
will be linking to this.

Note that off_t is not defined in standard C; it's defined by POSIX.

comp.lang.c Answers to Frequently Asked Questions (FAQ List)	15	Apr 1, 2006
comp.lang.c Answers to Frequently Asked Questions (FAQ List)	1	Feb 1, 2004

Why C is really a bad programming language

Nobody

Nobody

Nick Keighley

Phil Carmody

James Kuyper

Guest

Guest

Guest

Guest

Guest

jameskuyper

Guest

Guest

Guest

Beej Jorgensen

Guest

Guest

Guest

Guest

Keith Thompson

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads