[so] SIZE_MAX vs SSIZE_MAX

[Pascu Corneliu Florin]

OK , am inteles nevoia de a avea un signed pentru iesire ca sa poate da
return -1 in caz de eroare .
Ce nu intelegeam se reduce la : size_t e unsigned si apartine [0,
4294967296] si
ssize_t e signed si apartine [-214783647, 214783647] ( am dat printf pe
sistemul meu , dar
cred ca sunt definite asa in limits.h).
Orice read care incearca sa citeasca intre [ 214783647 + 1, 4294967296]
ar putea face asta din definita read-ului dar ar avea intotdeauna
comportament undefined.
Asa este sau  ceva imi scapa :)? Mi s-a parut dubios .


2014-03-12 9:02 GMT+02:00 Razvan Deaconescu <razvan.deaconescu at cs.pub.ro>:

> Pascu Corneliu Florin <pascucorneliuflorin at gmail.com> writes:
> > Salut,
> >
> > Din ce vad read are urmatoarea declaratie  *ssize_t* read(int fd , void *
> > buff, *size_t* len);
> > Totul este ok , dar ce se intampla cand fac ceva de genul: *read(fd,
> buff,
> > SIZE_MAX)*;
> > SIZE_MAX vad ca este 0xffffffff , iar SSIZE_MAX este 0x7fffffff.  Orice
> > read cu len>SSIZE_MAX
> > este undefined , right? Atunci de ce este len size_t definit in POSIX si
> nu
> > ssize_t ?
>
> Clarifică, te rugăm, ultima întrebare. E vorba de parametrul `len' al
> apelului `read'? Și întrebi de ce tipul acestuia este `size_t' și nu
> `ssize_t'?
>
> Dacă aceea este întrebarea, `len' este de tipul `size_t' pentru că este
> o dimensiune de buffer; dimensiunile sunt tot timpul pozitive. Apelul
> `read' întoarce un rezultat în formatul `ssize_t' pentru că este o
> valoare de retur. Aceasta poate fi negativă (-1) în caz de eroare sau
> pozitivă în cazul unui apel reușit.
>
> Legat de penultima întrebare, uite ce spune în pagina de manual[1]:
> ---
> If count is greater than SSIZE_MAX, the result is unspecified.
> ---
>
> [1] http://man7.org/linux/man-pages/man2/read.2.html
>
> Răzvan
> _______________________________________________
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20140312/9006ed08/attachment.html>