After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597390 - gda_binary_to_string() returns text with newlines
gda_binary_to_string() returns text with newlines
Status: RESOLVED FIXED
Product: libgda
Classification: Other
Component: Client library
4.1.x
Other Linux
: Normal normal
: ---
Assigned To: malerba
gnome-db Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-05 08:30 UTC by Murray Cumming
Modified: 2011-11-01 16:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Murray Cumming 2009-10-05 08:30:49 UTC 
In Glom, when generating a string to represent the binary data of a large image, with gda_binary_to_string(), I find that the text has newlines every few (255?) characters. That's not intended, right?
Comment 1 Murray Cumming 2009-10-05 09:00:54 UTC 
Sometimes there is also a " in there, as well as other strange characters. Is that intended?

For instance, here is a sample of the start of a large string that I get back from gda_binary_to_string():

1973-05-11,\211PNG\015
\032
\000\000\000\015IHDR\000\000\000\360\000\000\001@\010\002\000\000\000\015\212f\004\000\000\000\003sBIT\010\010\010\333\341O\340\000\000 \000IDATx\234\304\275\333\256$Ir ff\356\036\021y=\227:\247\352TuW\367ts\206=\034.\207\344R"H\002\242\010\351\201+a\005\001\202\004A\300J\330\027}\201V\372\017\351\013\364&\010\320\003\337EA\334%\227\344\354\222\273\340r8\354\231\236\276Lw]\3175O^"\343\342n\246\207\210\214\214\214[F\236jI\336\247\2632-\334\315\315\335\315\315\315\315\315-\360\037\375\367\377\033\000`-e\300\342\321\366\247\242\362#\330$\245\024\224R\371Q#\220\210\2723\364\306\223\177\027\221\266<{\221\264\321SF[\311_\374\254\364U\231\214r\021f\256\344\354\316\277\227\236\376Mk\243\277N\017\000\000rc\275m\364T\2207V\275\233S\232\200\255\245*\355-\200\025\270l\222.\010-X\271\014)\303sH\215\364n.\354`\254\236\375\2767O\031\270w\274{\316\231\372\323\275CU\251\275\317\204\021\221>\355\355\310P\374l\233xm\220\326>l!\240\215\260r\023\372\365\325\376\011\331\226\241\334\306z\3033\270.OP"*\263oQrg\02271\350\203\231\373a\014\267\013i\356\240C%t[j\2433\353\307\275\324V\350)\367~\366\275\302\350\017f\350\356lm\300\306E\243\203\376\275\204\355\315\237u\300\241b\245\255\267a\263\312\025k\235n\224\307\225\237}\030zoG\037\232\341\301x\372g\333\313\364\337
\236\236\353UOz\372\224=\210\324\332g\203\244\357 \346@\361|\330\212\327\221\255\2622\024\222BC\241\203f\017\020 \343[\312\331W\000\000\001\021\245\306\270\3659\335Aee\222\325\347\\\343,\254/\312\207\212\306n`\317n\255g\356\256\256Q\242W\306\262Qf\367\220p\015:eG\275}\246M\333*\324MI7\266\216\022=1Wp\366l\270\256\020T\225\3075`\237\006\364\351\232\007K\350:\260QH\364\344\373\016j\273\363\324u\342J\215\035\235\320\306\320\017\240\344\335\273q\347\223v\330\246\215\3166\344\337
Comment 2 Murray Cumming 2009-10-05 09:03:09 UTC 
Please ignore the "1973-05-11," there.
Comment 3 malerba 2009-10-06 09:10:46 UTC 
This is the intended behaviour, as the purpose of this function is to provide, as much as possible, a human readable dump of binary data. Printable characters as well as newline and the '\' character are printed AS-IS.

See gda-value.c::gda_binary_to_string().
Comment 4 Murray Cumming 2009-10-06 10:24:30 UTC 
OK. I suggest that the documentation might mention that as a helpful clue. Otherwise I might think that I can use this, for instance, directly in SQL, or (in my case) a .csv file.