John Utz <[EMAIL PROTECTED]> wrote: < this line makes unwarranted assumptions about pointer quality. i say < 'unwarranted' because if the implication of this code was warranted, you < wouldnt fire the assertion :-).
Not necessarily true, since selecting the wrong run-time heap can cause this problem. < i havent looked at the api, but i am sure that it isnt guaranteed not to < fail on occasion. It's often better to look an the API documentation/code before commenting, as you can avoid confusing people in your reply that way. It certainly can fail, but a quick look at the code makes it clear that you'll always get back a non-null pointer, although it may have garbage contents. Not ideal, but that's life. Better failure behavior might be to return a string of length 0, but returning null would probably break too much code. > And...it actually allocs the buffer and gives it back to you? man, i hate > that. great way to create mem leaks if the caller is sloppy. i do > recognize why someone might choose to code it that way cause there are > lots of obvious benefits...but.... The API documentation is explicit about who owns the pointer. Anyone who uses an API without understanding it has bigger problems than a memory leak. This API is not perfect, but it's handy, and very popular. If you want to avoid dynamically allocated pointers, there are other facilities in Xerces for transcoding into your own buffer. It's just much more complicated, as there's no absolute way of knowing in advance how much buffer space you'll need. On the other hand, I agree that naked pointers to dynamically allocated memory are problematic, and I always avoid them when possible. > note that the strcpy() will work even if the ptr's shite. but the delete > will barf, which fires your catch, which then retrys the delete....oh ick. Not necessarily -- it depends on the "shite-level" of the pointer. A pointer which points to valid memory, and happens to have a null byte somewhere will "work", but a pointer to memory which is not accessible to the process, or is not null-terminated will definitely not "work". There's also no guarantee that deleting a bad pointer will throw an exception, since the behavior is undefined. > so, assuming that transcode() is coded the way i like it ( i dont know if > it is ) and either sets the ptr to NULL or leaves the ptr ALONE if it > doesnt have anything to attach to it: > > char *attrValC = NULL; > > attrValC = input.getNodeValue().transcode(); This makes no sense to me. A function must return a value (unless it throws an exception), and it has no knowledge of the initial value of attrValC, so it cannot "leave the ptr ALONE if it doesnt have anything to attach to it". Can you explain what you mean? > a final, tangentially related point: if you are expecting this code to run > on something other than a US Win32 machine than you *really* should avoid > using char! it will *break* on a widechar(UNICODE) Win32 machine ( with > widechar==everything !US ). but that's probably what transcode() expects, > so you probably are stuck. I really don't understand what you're saying here. A char is a char, and is never a wide char. This API exists only to transcode from the UTF-16 encoding of a string of Unicode characters to whatever the representation of that string would be in the local code page, if there is one. It certainly _will_ break if there's no way to represent the Unicode string in the local code page, but that has nothing to do with whether or not the machine is a "widechar(UNICODE) Win32 machine," whatever that's supposed to be. If my machine's code page is set to 1252, and I try to transcode a string with Chinese characters, then that's likely to fail. More generally, if all of my XML documents are in the same encoding (or a compatible encoding) as my machine's code page, then everything will be fine. If not, then I won't always be able to transcode strings to the local page and display them. I think it's better to explain and/or discuss the issues, rather than make some blanket statement that isn't very clear anyway. Robust XMl applications shouldn't make any assumptions about what encodings are used, and therefore should either never attempt to display application data values, or have reliable fallback behavior when transcoding fails. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
