Re: size_t problems

Ed Jensen wrote:
Richard Heathfield <rjh@xxxxxxxxxxxxxxx> wrote:
Why? Surely everyone has learned their lesson from the early 1990s - "don't rely on exact-size types, or your code will break one day" - haven't they?

Sometimes (most of the time?) C developers need to choose between:

1. Writing 100% portable code. This can be non-trivial and really
slow down your development. (However, I'm sure writing 100% portable
code doesn't slow down any of the geniuses HERE. I'm talking strictly
about MORTAL developers.)

2. Writing code that's portable to the platforms they're currently
targeting. And perhaps keeping in mind platforms they're likely to
need to support in the future.

It's easy to be smug and regurgitate the ivory tower attitude:

"Well, just write your C code so it's 100% portable in the first
place. Easy! Problem solved! Only dummies don't do that!"


And then, like heathfield, they discover that they published a book
(c unleashed) with in one page the assumption that
sizeof(int) == sizeof(int *).

It is easy to play the guru here. More difficult in reality.

The reality of the situation is that many developers who choose the
"100% portable path" may end up (1) being unemployed, because their
productivity is low compared to more pragmatic developers, or (2)
working 80+ hours per week in order to keep pace with those more
pragmatic developers.


who cares about the job?
c.lang.c is the only thing it counts

Of course, what's really happened in the market is that more and more
projects have abandoned C (and C++) for evil, horrible, limited,
short-sighted languages that made pragmatic choices like: fixed size
primitive types.

I personally try to walk the fine line between "TOO pragmatic" and
"TOO ivory tower". I'm not quite ready to look down my nose and
admonish those developers that sometimes used "int" when they should
have used "size_t". (I do agree, however, that they should fix their
code the right way, if they decide to continue to use C.)

The problem, if you care to see it as such, is really that C is aging,
and some of the choices made decades ago made sense then, but perhaps
don't make so much sense now, for an ever increasing number of
applications.

Because C was one of the first languages I knew well, and I had done
it for such a long time, it'll always have a soft spot in my heart.
However, I can't help but yearn for something very much in the C
tradition but updated and refreshed. A "C2" language, perhaps, where
there's no need for an alphabet soup of types, and where a "size_t"
type becomes unnecessary.

(a) far from being garbage, size_t is a useful type;
(b) the committee codified size_t is 1989, not 2007;
(c) far from being obsolete, code that uses proper types in the proper way is more likely to survive and flourish than code that does not.

In my opinion, (c) is only true in a limited sort of way. It's more
likely that developers will flee to languages that offer increased
productivity AND portability through fixed size types. Those
languages make (a) almost entirely, if not entirely, irrelevant.

That way you've got to keep on rewriting things.
Precisely. Whereas, if you use the proper types in the right way, you are less likely to have to do that.

When programming in C, it is, quite simply, too much of a productivity
killer to always make sure you're using the proper types in the right
way 100% of the time. This comment shouldn't be mistaken as an excuse
for developers to use "int" when they should use "size_t", though.
It's just a comment on C in general.


more about that later
.

Relevant Pages

  • Re: reference for beginner on configure/make/compile/linking/etc.
    ... COMPLETELY overly complex to me - maybe cause the developer tries to ... That said, if the developers know what they're doing, you won't see any OS ... be able to assert portability differences by grepping for ... - Assumptions on struct members, number of arguments to certain functions, ...
    (freebsd-questions)
  • Re: which: command not found
    ... package, or as a member of the small & portable set of utilities used ... a tool-rich environment for use in the tool-rich environment. ... sympathize with DJGPP developers and embedded developers who may not ... volunteer willing to do the portability work. ...
    (comp.os.msdos.djgpp)
  • Re: size_t problems
    ... Sometimes C developers need to choose between: ... Writing 100% portable code. ... Because C was one of the first languages I knew well, ... productivity AND portability through fixed size types. ...
    (comp.lang.c)
  • Re: Problem when defining my own string.h
    ... so this seems to be a known "idiom" among library ... developers.. ... don't recommend it (due to portability issues), but I think I can make ... You mean forward or backward slash? ...
    (microsoft.public.vc.language)
  • Re: When should use C?
    ... C might give you better portability when writing a library that's intended ... to be callable from different languages since most of languages allow ... importing of C libraries or calling of C functions. ...
    (comp.lang.c)