re-definition of standard types

[Roman Mashak]

Hello, All!

I often come across in open-source software definitions of standard types
with new names, for example:

typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
....

Why not to use types specified in C99 or Posix standards? I believe that's
what they are for: make code reading/maintaining easier, standard and
consistent.

With best regards, Roman Mashak. E-mail: mr*@tusur.ru

[Bart]

Roman Mashak wrote:

Hello, All!

I often come across in open-source software definitions of standard types
with new names, for example:

typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
...

Why not to use types specified in C99 or Posix standards? I believe that's
what they are for: make code reading/maintaining easier, standard and
consistent.

Because some people feel the need to have types that are "guaranteed"
to be of a certain length or precision under the false assumption that
it makes their code more portable.

Regards,
Bart.

[Harald van Dijk]

Roman Mashak wrote:

Hello, All!

I often come across in open-source software definitions of standard types
with new names, for example:

typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
...

Why not to use types specified in C99 or Posix standards?

One possibility is to make the code easier to port to platforms that
don't conform to C99 or POSIX (most Windows implementations, for
example).

[BRG]

Bart wrote:

Roman Mashak wrote:

>Hello, All!

I often come across in open-source software definitions of standard types
with new names, for example:

typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
...

Why not to use types specified in C99 or Posix standards? I believe that's
what they are for: make code reading/maintaining easier, standard and
consistent.

Because some people feel the need to have types that are "guaranteed"
to be of a certain length or precision under the false assumption that
it makes their code more portable.

Their assumption will not always be false.

Brian Gladman

[Malcolm]

"BRG" <br*@nowhere.orgwrote in message news

Bart wrote:

>Roman Mashak wrote:

>>Hello, All!

I often come across in open-source software definitions of standard
types
with new names, for example:

typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
...

Why not to use types specified in C99 or Posix standards? I believe
that's
what they are for: make code reading/maintaining easier, standard and
consistent.

Because some people feel the need to have types that are "guaranteed"
to be of a certain length or precision under the false assumption that
it makes their code more portable.

Their assumption will not always be false.

No. If you've got a really brilliant configuration mangement system in place
then redefining every basic type can allow for clean recompiles.

The vast majority of people don't, in which case type such as SYS_CHAR
become a real nuisance. You must never call a standard library function with
a SYS_CHAR *, for example, or the whole system will break.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

[BRG]

Malcolm wrote:

"BRG" <br*@nowhere.orgwrote in message news

>Bart wrote:

>>Roman Mashak wrote:
Hello, All!

I often come across in open-source software definitions of standard
types
with new names, for example:

typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
...

Why not to use types specified in C99 or Posix standards? I believe
that's
what they are for: make code reading/maintaining easier, standard and
consistent.
Because some people feel the need to have types that are "guaranteed"
to be of a certain length or precision under the false assumption that
it makes their code more portable.

Their assumption will not always be false.

No. If you've got a really brilliant configuration mangement system in place
then redefining every basic type can allow for clean recompiles.

The vast majority of people don't, in which case type such as SYS_CHAR
become a real nuisance. You must never call a standard library function with
a SYS_CHAR *, for example, or the whole system will break.

The original poster claimed that the redefinition of types to obtain
types of guaranteed length or precision was based on the false
assumption that this makes their code more portable.

I pointed out _only_ that their assumption would not _always_ be false.

I am confused by your post because you respond 'No' to this point but
then go on to give details that are inconsistent with this response.

Brian Gladman

[websnarf]

Roman Mashak wrote:

I often come across in open-source software definitions of standard types
with new names, for example:

typedef char SYS_CHAR;
typedef unsigned short SYS_UINT16;
...

Why not to use types specified in C99 or Posix standards?

Maybe the code was written before 1999? Anyhow, C99 is not a widely
adopted standard. If you want to use the C99 stdint.h interface on
many non-C99 compilers, you can use something like my pstdint.h file:

http://www.pobox.com/~qed/pstdint.h

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Malcolm]

"BRG" <br*@nowhere.orgwrote

The original poster claimed that the redefinition of types to obtain
types of guaranteed length or precision was based on the false
assumption that this makes their code more portable.

I pointed out _only_ that their assumption would not _always_ be false.

I am confused by your post because you respond 'No' to this point but
then go on to give details that are inconsistent with this response.

You asserted a negative so "no" signifies concurrence.

Redefining every basic type can make code more portable, if you really know
what you are doing and the code is a self-contained unit.
Generally it is a bad idea that makes code hard to reuse, maybe even hard to
port.

--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

[BRG]

Malcolm wrote:

"BRG" <br*@nowhere.orgwrote

>The original poster claimed that the redefinition of types to obtain
types of guaranteed length or precision was based on the false
assumption that this makes their code more portable.

I pointed out _only_ that their assumption would not _always_ be false.

I am confused by your post because you respond 'No' to this point but
then go on to give details that are inconsistent with this response.

You asserted a negative so "no" signifies concurrence.

Ok, thanks, I did not read it this way.

Redefining every basic type can make code more portable, if you really know
what you are doing and the code is a self-contained unit.

Or, as with many cryptographic algorithms, when the specification of an
algorithm calls for a specific width type. This will often mean that
what has to be typed as an integer on one class of machine will have to
be typed as a long integer on another machine class. On some systems it
can even mean that the type has to be switched when the compiler flags
are switched.

Generally it is a bad idea that makes code hard to reuse, maybe even hard to
port.

I agree that this is not always good and not always bad in portability
terms. Whether there are portability benefits or a detrimental impact on
portability in doing this is not something that can be stated as an
absolute fact because it is dependent on the applications context.

Which is why I contested the original claim.

Brian Gladman

[Thad Smith]

we******@gmail.com wrote:

If you want to use the C99 stdint.h interface on
many non-C99 compilers, you can use something like my pstdint.h file:

http://www.pobox.com/~qed/pstdint.h

While I like the idea of writing a stdint.h for older compilers, I am
puzzled by your comment preceding definitions of int_fastX_t definitions:

* The ANSI C committee pretending to know or specify anything about
* performance is the epitome of misguided arrogance. The mandate of

My understanding is that the definitions allow the implementor to
specify what is fast (efficient) on the target system. That sounds
helpful to me. Where, in your opinion, is the misguided arrogance?

--
Thad