Re: Boost process and C

websnarf@xxxxxxxxx wrote:
Flash Gordon wrote:
websnarf@xxxxxxxxx wrote:
Ben C wrote:
On 2006-05-03, websnarf@xxxxxxxxx <websnarf@xxxxxxxxx> wrote:
CBFalconer wrote:
websnarf@xxxxxxxxx wrote:
CBFalconer wrote:
... snip ...
The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities
You perhaps would like to name one?
I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.
[snip]

[...] I did find an explanation and
justification for this. Conceded, such a size is probably adequate
for most usage, but the restriction is not present in standard C
strings.
Your going to need to conceed on more grounds than that. There is a
reason many UNIX systems tried to add a ssize_t type, and why TR 24731
has added rsize_t to their extension. (As a side note, I strongly
suspect the Microsoft, in fact, added this whole rsize_t thing to TR
24731 when they realized that Bstrlib, or things like it, actually has
far better real world safety because its use of ints for string
lengths.) Using a long would be incorrect since there are some systems
where a long value can exceed a size_t value (and thus lead to falsely
sized mallocs.) There is also the matter of trying to codify
read-only and constant strings and detecting errors efficiently
(negative lengths fit the bill.) Using ints is the best choice
because at worst its giving up things (super-long strings) that nobody
cares about,
I think it's fair to expect the possibility of super-long strings in a
general-purpose string library.
Ok, so you can name a single application of such a thing right?
Handling an RTF document that you will be writing to a variable length
record in a database. Yes, I do have good reason for doing this. No, I
can't stream the document in to the database so I do have to have it all
in memory. Yes, RTF documents are encoded as text. Yes, they can be
extremely large, especially if they have graphics embedded in them
encoded as text.

So now name the platform where its *possible* to deal with this, but
where Bstrlib fails to be able to deal with them due to its design
choices.

If the DOS port hadn't been dropped then depending on the compiler we might have hit this. A significant portion of the SW I'm thinking of originated on DOS, so it could have hit it.

it allows in an efficient way for all desirable encoding scenarios,
and it avoids any wrap around anomolies causing under-allocations.
What anomalies? Are these a consequence of using signed long, or
size_t?
I am describing what int does (*BOTH* the encoding scenarios and
avoiding anomolies), Using a long int would allow for arithmetic on
numbers that exceed the maximum value of size_t on some systems (that
actually *exist*), so when there was an attempt to malloc or realloc on
such sizes, there would be a wrap around to some value that would just
make it screw up. And if I used a size_t, then there would be no
simple space of encodings that can catch errors, constants and write
protected strings.
Is an extra byte (or word, or double word) for a flags field really that
big an overhead?

I need two *bits* for flags, and I want large ranges to catch errors in
the scalar fields (this is a *safe* library). An extra struct entry is
the wrong way to do this because it doesn't help my catch errors in the
scalar fields, and its space inefficient.

ssize_t would have been a reasonable *functional* choice, but its not
standard. size_t is no good because it can't go negative. long int is
no good because there are plenty of real platforms where long int is
larger than size_t. int solves all the main real problems, and as a
bonus the compiler is designed to make sure its the fastest scalar
primitive available.

Strangely enough, when a previous developer on the code I'm dealing with thought he could limit size to a "valid" range an assert if it was out of range we found that the asserts kept getting triggered. However, it was always triggered incorrectly because the size was actually valid! So I'll stick to not artificially limiting sizes. If the administrator of a server the SW is installed on wants then s/he can use system specific means to limit the size of a process.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
.

Relevant Pages

  • Re: Boost process and C
    ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... where Bstrlib fails to be able to deal with them due to its design ... If the DOS port hadn't been dropped then depending on the compiler we ...
    (comp.lang.c)
  • Re: Boost process and C
    ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... If the DOS port hadn't been dropped then depending on the compiler we ... And how do you deal with the fact that the language limits your sizes ...
    (comp.lang.c)
  • Re: Boost process and C
    ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... I do have good reason for doing this. ... If the DOS port hadn't been dropped then depending on the compiler we ...
    (comp.lang.c)
  • Re: Boost process and C
    ... snip ... ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... Handling an RTF document that you will be writing to a variable length record in a database. ...
    (comp.lang.c)
  • Re: Boost process and C
    ... of int for sizes, rather than size_t. ... read-only and constant strings and detecting errors efficiently ... Handling an RTF document that you will be writing to a variable length ... the scalar fields. ...
    (comp.lang.c)
Loading