Closed b-carr closed 3 years ago
Hi @b-carr I'm currently recovering from the second vaccine, I'll have a closer look soon-ish.
Hi @b-carr I have some updates:
uriUriStringToUnixFilename
to the library for convenience was a bad idea. It does not do the proper URI spec parsing that uriParseSingleUri
does, but some basic detection and copying strings around.file:///etc/passwd
rather than file:/etc/passwd
, at least until RFC8089 of 2017).uriFreeUriMembers
when freeing path segment "012[..]890" using plain free
, at least over here, but it happens only some of the time. Cool! :wink: calloc
and is trying to be freed by free
, with the original call return value and no realloc happening in between. So that's something that "should not fail" and indicates "things being very off"."file:/012[..]678"
and length strlen(test_uri)-6
, memcpy copies into post allocation space and my guess is that that cause memory corruption.So to summarize, I think:
len(uriString) + 1 - 5
for the de-facto worst case.What do you think?
Works for me, thanks!
I'm experimenting with using the library and came across a strange bug. I started with this code:
which, when compiled with gcc v7.5.0 fails with message
I did some fiddling and found 2 ways to make the code work. First, by moving the call to
uriFreeUriMembersA
before the call touriUriStringToUnixFilenameA
, giving this code:The second way to make it work is to replace the
6
with a4
in the computation of the length offilename
, so this code:The documentation indicates
6
is the correct offset, but I tried the4
becausefile:
is 5 characters long, so subtract 1 to give space for the finalNULL
byte.I'm not sure if this is me misusing the library or a bug in the library, but I would appreciate any insight.
Edited to add: It's also not consistent across
test_uri
lengths. For example, if I add90
to the end oftest_uri
the first example works. But if I only add
9
it fails.