Re: [Libreoffice] Making our Own Banned.h
Hey, Oh I just love this code, but are we actually planning on using the size-bounded string functions like strlcpy(3)? Because then you have to consider that these are not part of glibc so we will have to ship our own version which is not a big deal at all It would be a huge effort to switch all of the code to use these functions, but I think it would worth it. On (2011-06-20 09:51), Marc-André Laverdičre wrote: Hello list. As you all know, there are a bunch of old C APIs that make security vulnerabilities trivial to implement. And doing a git grep tells me that we use those a plenty. Now, not all of it may create vulnerabilities, but it is good practice to migrate away from those as much as possible. Microsoft has compiled a useful list: http://msdn.microsoft.com/en-us/library/bb288454.aspx And they have made a header (I'm attaching here) that works on their compiler. Now, I think we should make it multi-platform, so that the whole code base can benefit from it. The transition must be gradual, for sure, but I think we'd benefit a lot from it in the long run. What are the compilers that we must handle? - Gcc TODO - Microsoft's DONE - Sun's cc family ??? - Intel's ??? Regards, -- Marc-André Laverdičre Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India /*** * banned.h - list of Microsoft Security Development Lifecycle (SDL) banned APIs * * Purpose: * This include file contains a list of banned APIs which should not be used in new code and * removed from legacy code over time. * * History * 01-Jan-2006 - mikehow - Initial Version * 22-Apr-2008 - mikehow - Updated to SDL 4.1, commented out recommendations and added memcpy * 26-Jan-2009 - mikehow - Updated to SDL 5.0, made the list sane, added SDL compliance levels * 10-Feb-2009 - mikehow - Updated based on feedback from MS Office * 12-May-2009 - jpardue - Added wmemcpy * 08-Jul-2009 - mikehow - Fixed header #ifndef/#endif logic, made the SDL recommended compliance level name more obvious * 05-Nov-2009 - mikehow - Added vsnprintf (ANSI version of _vsnprintf) * 01-Jan-2010 - mikehow - Added better strsafe integration, now the following works: * #include strsafe.h * #include banned.h * 04-Jun-2010 - mikehow - Small #if bug fix * * ***/ #ifndef _INC_BANNED # define _INC_BANNED # if defined(_MSC_VER) # pragma once // SDL 5.0 and later Requirements # if defined(_STRSAFE_H_INCLUDED_) !defined(STRSAFE_NO_DEPRECATE) // Only deprecate what's not already deprecated by StrSafe # pragma deprecated (_mbscpy, _mbccpy) # pragma deprecated (strcatA, strcatW, _mbscat, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccat) # pragma deprecated (strncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynW) # pragma deprecated (strncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, lstrncat, lstrcatnA, lstrcatnW, lstrcatn) # pragma deprecated (IsBadWritePtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadHugeReadPtr, IsBadCodePtr, IsBadStringPtr) # pragma deprecated (memcpy, RtlCopyMemory, CopyMemory, wmemcpy) # else // StrSafe not loaded, so deprecate everything! # pragma deprecated (strcpy, strcpyA, strcpyW, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, _tccpy, _mbccpy, _ftcscpy) # pragma deprecated (strcat, strcatA, strcatW, wcscat, _tcscat, _mbscat, StrCat, StrCatA, StrCatW, lstrcat, lstrcatA, lstrcatW, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccat, _ftcscat) # pragma deprecated (sprintfW, sprintfA, wsprintf, wsprintfW, wsprintfA, sprintf, swprintf, _stprintf) # pragma deprecated (wvsprintf, wvsprintfA, wvsprintfW, vsprintf, _vstprintf, vswprintf) # pragma deprecated (strncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynW) # pragma deprecated (strncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, StrCatN, StrCatNA, StrCatNW, StrNCat, StrNCatA, StrNCatW, lstrncat, lstrcatnA, lstrcatnW, lstrcatn) # pragma deprecated (gets, _getts, _gettws) # pragma deprecated (IsBadWritePtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadHugeReadPtr, IsBadCodePtr, IsBadStringPtr) # pragma deprecated (memcpy,
Re: [Libreoffice] [PATCH] [PUSHED:master] Additional fix for bug fdo#33781
Pushed to master, but I am not sure if this is a serious enough bug to push to 3-4 (or 3-4-1)? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [REVIEWED] Remove obsolete Win95/NT code
Looks fine to me, feel free to push to master (you have push rights, don't you?). --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Autogen switch --with-agfa-monotype-fonts fails to download fonts tarball, Win32 build-only switch ?
You are not supposed to use that switch unless you have these (proprietary) fonts and the right to redistribute them to your customers. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [REVIEWED:master, 3-4] fix fdo#37110 --quickstart shouldn't show start center
Go ahead and push to master and 3-4. Two more reviews needed for 3-4-1, unless it is already too late for that. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Autogen switch --with-agfa-monotype-fonts fails to download fonts tarball, Win32 build-only switch ?
Le 20/06/11 10:08, Tor Lillqvist a écrit : Hi Tor, You are not supposed to use that switch unless you have these (proprietary) fonts and the right to redistribute them to your customers. All fair enough, but is that actually mentioned anywhere in the config switch help ? Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Sun, 2011-06-19 at 12:04 +0200, Julien Nabet wrote:
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_process.so
I took a look at the git history of sal module and found nothing special.
Does it happen every time, or some times. I think there's a
race/threading bug in there that doesn't get triggered everytime.
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Interesting difference in thread-specific data function semantics for Windows vs. Unix
On Sun, 2011-06-19 at 14:10 -0600, Tor Lillqvist wrote: When run on Linux, I see no such problems. I see a problem about once in 10 or 20 runs under valgrind. I was poking at this last week to see if I could flush the problem out. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
--- En date de : Lun 20.6.11, Caolán McNamara caol...@redhat.com a écrit :
De: Caolán McNamara caol...@redhat.com
Objet: Re: [Libreoffice] Debug compilation fails in sal module
À: Julien Nabet serval2...@yahoo.fr
Cc: libreoffice@lists.freedesktop.org
Date: Lundi 20 juin 2011, 10h57
On Sun, 2011-06-19 at 12:04 +0200,
Julien Nabet wrote:
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester
../../../unxlngi6/lib/libosl_process.so
I took a look at the git history of sal module and
found nothing special.
Does it happen every time, or some times. I think there's
a
race/threading bug in there that doesn't get triggered
everytime.
Hello,
It happens each time. I don't know what element has triggered this.
I tried gdb but when I runned it, it makes the first which is ok. I don't know
how to go to this specific test.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [REVIEWED] Remove obsolete Win95/NT code
Looks fine to me, feel free to push to master (you have push rights, don't you?). Pushed. -- Jesús Corrius je...@softcatala.org Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC][Report] MultiLine InputBar
Hi Anurag On 19/06/11 10:10, Anurag Jain wrote: Hello Kohei, Noel This is the brief of my work for this week. As I was supposed to create a new container class which will contain ScTextWnd obejct + ScrollBar + Button object, I've done so. Also I've tunneled the calls to ScTextWnd from ScInputWindow via the new methods created into the ScInputBarGroup(new class which I've created). ok, sounds reasonable, do you have a patch, I will apply it for you to the feature branch But the problem I'm facing is now when I removed the aTextWnd.Show() from constructor of ScInputWindow and added it into the ScInputBarGroup's constructor the inputbar will not appear. I've passed the ScInputBarGroup's object in InsertWindow() function though. But Still not able to figure out what might be the problem. hmm, I just built your feature branch on Friday and tried to get my head around the task ( and it is still a little unfamiliar to me ), I am sure though I could help though with your latest problem when I have a patch with your latest work :-) I'm working on it. Hope I'll figure it out soon and I'm not able to come online because of the internet connection problem; but it will be resolved soon. please let me know when you are available online and we can have a chat ( my nick is noelp ) I am around normal european working hours ( and of course sometimes later than that too ;-) ). Be good at least to touch base. Noel Thanks and regards ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Autogen switch --with-agfa-monotype-fonts fails to download fonts tarball, Win32 build-only switch ?
Le 20/06/11 10:53, Alexander Thurgood a écrit : In fact, what is written is not very clear : --with-agfa-monotype-fonts Do not include the proprietary Agfa Monotype fonts (even if present) in the LibreOffice installation set. whereas it would probably be better to state something like : This switch should only be enabled for those who have the right to use or distribute the proprietary Agfa Monotype fonts. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Andrea, On Sat, 2011-06-18 at 14:57 +0200, Andrea Pescetti wrote: Would it be possible to have some more information about the security issues fixed in LibreOffice 3.3 ? Sure - this is what the agenda item is about; AFAIR there is only one interesting one, that is a Lotus Word Pro related issue. At least, a short description of each issue and information on whether they affect/affected the 3.4 series too ? It doesn't affect 3.4.x - we fixed it there early, and released 3.4.x silently with the fix, and CERT should have announced post 3.3.x - but sure ... We need people who in addition to coping with the tedium of reacting to the security issues, providing fixes and testing them on older branches - also like to write them up. This is an important factor for people considering to upgrade their current LibreOffice installation Sure - so - there is certainly a space to do this sort of thing in the security team if you want to get stuck in ? and of course, we can't use usual means for this - the bugs / patches are not tracked in bugzilla etc. so it needs some manual effort. Do you know anyone that would want to help out with that admin ? ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Olivier, On Sat, 2011-06-18 at 08:25 -0300, Olivier Hallot wrote: Can such minutes be posted in TDF blog? I think it deserves publicity: Either for its content and for visibility + vitality of the TSC and LibreOffice. Again, it'd be wonderful if someone wanted to do that. Having said that, the minutes are extremely succinct - ie. you have to be a hacker to understand them ;-) and (personally) I'd resist spending even more time making them very verbose chatty. Though, of course if someone wants to come to the TSC meetings and write a longer verbose screed on what was said to post on the blog, that is fine too. Of course, if the existing format is fine, and/or we can just expand where necessary via questions on the blog itself (perhaps) then it shouldn't be too hard to post what is there. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Patch] [Pushed] Question about sal/qa/osl/process/osl_Thread.cxx
Hi Julien, On Sat, 2011-06-18 at 14:09 +0200, Julien Nabet wrote: Ok, so I added the 2 break instructions, commited and pushed on master. Thank you ! Nice :-) it's good to see this stream of snafu's cleaned up over time. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
Hello, That's a good question. I'm in the don't code it if you don't have to school of thought, so I'm not too hot in implementing those... Is there a way to detect if our platform has it and use it. And if our platform doesn't have it, define some macro that would have a functionally identical code? I'm guessing the performance would be a little lower in those cases, but there is no point reinventing the wheel, no? If we feel like implementing something, I'm suggesting ISO/IEC TR 24731. This looked like the best API for avoiding buffer overflows. It is implemented by Microsoft, but sadly it seems like we don't have it in glibc Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 06/20/2011 11:57 AM, Robert Nagy wrote: Hey, Oh I just love this code, but are we actually planning on using the size-bounded string functions like strlcpy(3)? Because then you have to consider that these are not part of glibc so we will have to ship our own version which is not a big deal at all It would be a huge effort to switch all of the code to use these functions, but I think it would worth it. On (2011-06-20 09:51), Marc-André Laverdičre wrote: Hello list. As you all know, there are a bunch of old C APIs that make security vulnerabilities trivial to implement. And doing a git grep tells me that we use those a plenty. Now, not all of it may create vulnerabilities, but it is good practice to migrate away from those as much as possible. Microsoft has compiled a useful list: http://msdn.microsoft.com/en-us/library/bb288454.aspx And they have made a header (I'm attaching here) that works on their compiler. Now, I think we should make it multi-platform, so that the whole code base can benefit from it. The transition must be gradual, for sure, but I think we'd benefit a lot from it in the long run. What are the compilers that we must handle? - Gcc TODO - Microsoft's DONE - Sun's cc family ??? - Intel's ??? Regards, -- Marc-André Laverdičre Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India /*** * banned.h - list of Microsoft Security Development Lifecycle (SDL) banned APIs * * Purpose: * This include file contains a list of banned APIs which should not be used in new code and * removed from legacy code over time. * * History * 01-Jan-2006 - mikehow - Initial Version * 22-Apr-2008 - mikehow - Updated to SDL 4.1, commented out recommendations and added memcpy * 26-Jan-2009 - mikehow - Updated to SDL 5.0, made the list sane, added SDL compliance levels * 10-Feb-2009 - mikehow - Updated based on feedback from MS Office * 12-May-2009 - jpardue - Added wmemcpy * 08-Jul-2009 - mikehow - Fixed header #ifndef/#endif logic, made the SDL recommended compliance level name more obvious * 05-Nov-2009 - mikehow - Added vsnprintf (ANSI version of _vsnprintf) * 01-Jan-2010 - mikehow - Added better strsafe integration, now the following works: * #include strsafe.h * #include banned.h * 04-Jun-2010 - mikehow - Small #if bug fix * * ***/ #ifndef _INC_BANNED # define _INC_BANNED # if defined(_MSC_VER) # pragma once // SDL 5.0 and later Requirements # if defined(_STRSAFE_H_INCLUDED_) !defined(STRSAFE_NO_DEPRECATE) // Only deprecate what's not already deprecated by StrSafe # pragma deprecated (_mbscpy, _mbccpy) # pragma deprecated (strcatA, strcatW, _mbscat, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccat) # pragma deprecated (strncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynW) # pragma deprecated (strncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, lstrncat, lstrcatnA, lstrcatnW, lstrcatn) # pragma deprecated (IsBadWritePtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadHugeReadPtr, IsBadCodePtr, IsBadStringPtr) # pragma deprecated (memcpy, RtlCopyMemory, CopyMemory, wmemcpy) # else // StrSafe not loaded, so deprecate everything! # pragma deprecated (strcpy, strcpyA, strcpyW, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, _tccpy, _mbccpy, _ftcscpy) # pragma deprecated (strcat, strcatA, strcatW, wcscat, _tcscat, _mbscat, StrCat, StrCatA, StrCatW, lstrcat, lstrcatA, lstrcatW, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccat, _ftcscat) # pragma deprecated (sprintfW, sprintfA, wsprintf, wsprintfW, wsprintfA, sprintf, swprintf, _stprintf) #
Re: [Libreoffice] Making our Own Banned.h
Hello, Well you don't have it any other supported platforms either. You can't just use macros to use those whenever they are supported, we would have to walk through the code and convert each by hand. If we don't do this there is no real point in listing strcpy and friends in banned.h. On (2011-06-20 15:30), Marc-André Laverdi??re wrote: Hello, That's a good question. I'm in the don't code it if you don't have to school of thought, so I'm not too hot in implementing those... Is there a way to detect if our platform has it and use it. And if our platform doesn't have it, define some macro that would have a functionally identical code? I'm guessing the performance would be a little lower in those cases, but there is no point reinventing the wheel, no? If we feel like implementing something, I'm suggesting ISO/IEC TR 24731. This looked like the best API for avoiding buffer overflows. It is implemented by Microsoft, but sadly it seems like we don't have it in glibc Marc-André Laverdi??re Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 06/20/2011 11:57 AM, Robert Nagy wrote: Hey, Oh I just love this code, but are we actually planning on using the size-bounded string functions like strlcpy(3)? Because then you have to consider that these are not part of glibc so we will have to ship our own version which is not a big deal at all It would be a huge effort to switch all of the code to use these functions, but I think it would worth it. On (2011-06-20 09:51), Marc-André Laverdičre wrote: Hello list. As you all know, there are a bunch of old C APIs that make security vulnerabilities trivial to implement. And doing a git grep tells me that we use those a plenty. Now, not all of it may create vulnerabilities, but it is good practice to migrate away from those as much as possible. Microsoft has compiled a useful list: http://msdn.microsoft.com/en-us/library/bb288454.aspx And they have made a header (I'm attaching here) that works on their compiler. Now, I think we should make it multi-platform, so that the whole code base can benefit from it. The transition must be gradual, for sure, but I think we'd benefit a lot from it in the long run. What are the compilers that we must handle? - Gcc TODO - Microsoft's DONE - Sun's cc family ??? - Intel's ??? Regards, -- Marc-André Laverdičre Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India /*** * banned.h - list of Microsoft Security Development Lifecycle (SDL) banned APIs * * Purpose: * This include file contains a list of banned APIs which should not be used in new code and * removed from legacy code over time. * * History * 01-Jan-2006 - mikehow - Initial Version * 22-Apr-2008 - mikehow - Updated to SDL 4.1, commented out recommendations and added memcpy * 26-Jan-2009 - mikehow - Updated to SDL 5.0, made the list sane, added SDL compliance levels * 10-Feb-2009 - mikehow - Updated based on feedback from MS Office * 12-May-2009 - jpardue - Added wmemcpy * 08-Jul-2009 - mikehow - Fixed header #ifndef/#endif logic, made the SDL recommended compliance level name more obvious * 05-Nov-2009 - mikehow - Added vsnprintf (ANSI version of _vsnprintf) * 01-Jan-2010 - mikehow - Added better strsafe integration, now the following works: * #include strsafe.h * #include banned.h * 04-Jun-2010 - mikehow - Small #if bug fix * * ***/ #ifndef _INC_BANNED # define _INC_BANNED # if defined(_MSC_VER) # pragma once // SDL 5.0 and later Requirements # if defined(_STRSAFE_H_INCLUDED_) !defined(STRSAFE_NO_DEPRECATE) // Only deprecate what's not already deprecated by StrSafe # pragma deprecated (_mbscpy, _mbccpy) # pragma deprecated (strcatA, strcatW, _mbscat, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccat) # pragma deprecated (strncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynW) # pragma deprecated (strncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, lstrncat, lstrcatnA, lstrcatnW, lstrcatn) # pragma deprecated (IsBadWritePtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadHugeReadPtr, IsBadCodePtr, IsBadStringPtr) # pragma deprecated (memcpy, RtlCopyMemory, CopyMemory, wmemcpy) # else // StrSafe not loaded, so deprecate everything! # pragma deprecated (strcpy, strcpyA, strcpyW, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, _tccpy, _mbccpy,
[Libreoffice] [PATCH] Re: Autogen switch --with-agfa-monotype-fonts fails to download fonts tarball, Win32 build-only switch ?
Le 20/06/11 11:18, Alexander Thurgood a écrit : whereas it would probably be better to state something like : This switch should only be enabled for those who have the right to use or distribute the proprietary Agfa Monotype fonts. Enclosed diff proposing change to configure switch help message text. Alex diff --git a/configure.in b/configure.in index 4485484..d44680d 100755 --- a/configure.in +++ b/configure.in @@ -580,9 +580,9 @@ AC_ARG_WITH(afms, AC_ARG_WITH(agfa-monotype-fonts, AS_HELP_STRING([--with-agfa-monotype-fonts], - [Do not include the proprietary Agfa Monotype fonts - (even if present) in the LibreOffice installation - set.]) + [This switch should only be enabled for those who have the right + to use or distribute the proprietary Agfa Monotype + fonts.]) ,) AC_ARG_WITH(epm, ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
btw., on openbsd you already get warnings if you use unsafe functions, like: (ws robert 45001)$ gcc `pkg-config --cflags --libs glib-2.0` -lkvm proc.c /usr/local/lib/libglib-2.0.so.2800.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libglib-2.0.so.2800.0: warning: strcpy() is almost always misused, please use strlcpy() On (2011-06-20 12:09), Robert Nagy wrote: Hello, Well you don't have it any other supported platforms either. You can't just use macros to use those whenever they are supported, we would have to walk through the code and convert each by hand. If we don't do this there is no real point in listing strcpy and friends in banned.h. On (2011-06-20 15:30), Marc-André Laverdi??re wrote: Hello, That's a good question. I'm in the don't code it if you don't have to school of thought, so I'm not too hot in implementing those... Is there a way to detect if our platform has it and use it. And if our platform doesn't have it, define some macro that would have a functionally identical code? I'm guessing the performance would be a little lower in those cases, but there is no point reinventing the wheel, no? If we feel like implementing something, I'm suggesting ISO/IEC TR 24731. This looked like the best API for avoiding buffer overflows. It is implemented by Microsoft, but sadly it seems like we don't have it in glibc Marc-André Laverdi??re Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 06/20/2011 11:57 AM, Robert Nagy wrote: Hey, Oh I just love this code, but are we actually planning on using the size-bounded string functions like strlcpy(3)? Because then you have to consider that these are not part of glibc so we will have to ship our own version which is not a big deal at all It would be a huge effort to switch all of the code to use these functions, but I think it would worth it. On (2011-06-20 09:51), Marc-André Laverdičre wrote: Hello list. As you all know, there are a bunch of old C APIs that make security vulnerabilities trivial to implement. And doing a git grep tells me that we use those a plenty. Now, not all of it may create vulnerabilities, but it is good practice to migrate away from those as much as possible. Microsoft has compiled a useful list: http://msdn.microsoft.com/en-us/library/bb288454.aspx And they have made a header (I'm attaching here) that works on their compiler. Now, I think we should make it multi-platform, so that the whole code base can benefit from it. The transition must be gradual, for sure, but I think we'd benefit a lot from it in the long run. What are the compilers that we must handle? - Gcc TODO - Microsoft's DONE - Sun's cc family ??? - Intel's ??? Regards, -- Marc-André Laverdičre Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India /*** * banned.h - list of Microsoft Security Development Lifecycle (SDL) banned APIs * * Purpose: * This include file contains a list of banned APIs which should not be used in new code and * removed from legacy code over time. * * History * 01-Jan-2006 - mikehow - Initial Version * 22-Apr-2008 - mikehow - Updated to SDL 4.1, commented out recommendations and added memcpy * 26-Jan-2009 - mikehow - Updated to SDL 5.0, made the list sane, added SDL compliance levels * 10-Feb-2009 - mikehow - Updated based on feedback from MS Office * 12-May-2009 - jpardue - Added wmemcpy * 08-Jul-2009 - mikehow - Fixed header #ifndef/#endif logic, made the SDL recommended compliance level name more obvious * 05-Nov-2009 - mikehow - Added vsnprintf (ANSI version of _vsnprintf) * 01-Jan-2010 - mikehow - Added better strsafe integration, now the following works: * #include strsafe.h * #include banned.h * 04-Jun-2010 - mikehow - Small #if bug fix * * ***/ #ifndef _INC_BANNED # define _INC_BANNED # if defined(_MSC_VER) # pragma once // SDL 5.0 and later Requirements # if defined(_STRSAFE_H_INCLUDED_) !defined(STRSAFE_NO_DEPRECATE) // Only deprecate what's not already deprecated by StrSafe # pragma deprecated (_mbscpy, _mbccpy) # pragma deprecated (strcatA, strcatW, _mbscat, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccat) # pragma deprecated (strncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynW) # pragma deprecated (strncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, lstrncat, lstrcatnA, lstrcatnW,
Re: [Libreoffice] Making our Own Banned.h
On Mon, 2011-06-20 at 09:51 +0530, Marc-André Laverdière wrote: Hello list. Now, I think we should make it multi-platform, so that the whole code base can benefit from it. The transition must be gradual, for sure, but I think we'd benefit a lot from it in the long run. I have to say, I'm kind of unenthusiastic about deprecating strlen and memcpy. All the exotic windows-only ones look like good candidates to enforce not using as a first cut though. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Re: Autogen switch --with-agfa-monotype-fonts fails to download fonts tarball, Win32 build-only switch ?
On Mon, 2011-06-20 at 12:10 +0200, Alexander Thurgood wrote: Enclosed diff proposing change to configure switch help message text. Looks good, PUSHED. I sort of wonder why we have that in there at all actually, but anyway. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] new development ideas
Hi, being new to the list, is there a specific topic for new development ideas? J -- This message is private and confidential and may also be legally privileged. If you have received this message in error, please email it back to the sender and immediately permanently delete it from your computer system. Please do not read, print, re-transmit, store or act in reliance on it or any attachments. British Airways may monitor email traffic data and also the content of emails, where permitted by law, for the purposes of security and staff training and in order to prevent or detect unauthorised use of the British Airways email system. Virus checking of emails (including attachments) is the responsibility of the recipient. British Airways Plc is a public limited company registered in England and Wales. Registered number: 177. Registered office: Waterside, PO Box 365, Harmondsworth, West Drayton, Middlesex, England, UB7 0GB. Additional terms and conditions are available on our website: www.ba.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [REVIEWED:master, 3-4] fix fdo#37110 --quickstart shouldn't show start center
On Mon, 2011-06-20 at 02:26 -0600, Tor Lillqvist wrote: Go ahead and push to master and 3-4. Two more reviews needed for 3-4-1, unless it is already too late for that. bug: https://bugs.freedesktop.org/show_bug.cgi?id=37110 patch: https://bugs.freedesktop.org/attachment.cgi?id=48149 Looks good to me; I assume we need one more approval to get it into 3.4.1. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] new development ideas
On Mon, 2011-06-20 at 11:14 +0100, julian.ashbo...@ba.com wrote: being new to the list, is there a specific topic for new development ideas? The list is for developers, and people discussing code. There are far more good ideas for development than there are people to work on them, and their discussion best belongs elsewhere, the tdf-discuss list perhaps. Then again - if you are a developer, and you are missing some ideas - then its great to ask here; and/or I'd try to get an easy hack or two completed first[1] - then people will be more inclined to help out with code pointers and advice for more complex tasks. Does that make sense ? All the best, Michael. [1] - http://wiki.documentfoundation.org/Development/Easy_Hacks -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
On (2011-06-20 15:30), Marc-André Laverdi??re wrote:
- Gcc TODO
For GCC you could redefine all of the functions with the deprecated
attribute like:
#include stdio.h
int printf(const char *format, ...) __attribute__((deprecated));
int
main()
{
printf();
return 0;
}
Which will end up as a compile time warning:
deprecated.c: In function 'main':
deprecated.c:8: warning: 'printf' is deprecated (declared at deprecated.c:3)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
I have to say, I'm kind of unenthusiastic about deprecating strlen and memcpy. I agree fully. I was under the impression that LO mostly uses its own (too many) string classes anyway, and usually for strings of UTF-16 (16-bit) elements (for lack of better word), seldom plain C library char string functions? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][PUSHED-3-4-0] fix quickstart on platforms using GTK and use the correct plugin name
Robert Nagy píše v Ne 19. 06. 2011 v 16:52 +0200: After switching to gbuild ENABLE_SYSTRAY_GTK was not defined in the sfx target and the plugin name for libqstart was also hardcoded for linux. It has been approved by me, Tor, and Michael = pushed into master, libreoffice-3-4 and libreoffice-3-4-1 branches. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Improvements to import/export of character attributes in HTML filter
Contributed under LGPLv3+ and MPL. Thanks, kiitoksia, pushed to master. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
On (2011-06-20 05:48), Tor Lillqvist wrote: I have to say, I'm kind of unenthusiastic about deprecating strlen and memcpy. I agree fully. I was under the impression that LO mostly uses its own (too many) string classes anyway, and usually for strings of UTF-16 (16-bit) elements (for lack of better word), seldom plain C library char string functions? --tml I think there are plenty of places in the lower level code that use these functions. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEWED][PUSHED-3-4-1] Re: [REVIEW] Regression from 3.3
Markus Mohrhard píše v Pá 17. 06. 2011 v 19:21 +0200: Oh, I had reviewed this patch already but forgot to write a mail. But I have no access to my 3-4 build, so would someone please push it for me. This was 3rd approval = pushed into 3-4-1 branch. Thanks for the contribution. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Mon, 2011-06-20 at 10:08 +0100, serv serva wrote: It happens each time. I don't know what element has triggered this. I tried gdb but when I runned it, it makes the first which is ok. I don't know how to go to this specific test. Could you see the patch in the other thread interesting difference in... and see if it makes a difference to this problem as well. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] REMINDER: Release 3.4.1-rc2 from libreoffice-3-4-1 branch
Hi, please note that the commit deadline for 3.4.1-rc2 is today, Jun 20, 2011. If no blocker is found, rc2 will be marked as final. See also http://wiki.documentfoundation.org/ReleasePlan#3.4_release http://wiki.documentfoundation.org/Release_Criteria http://wiki.documentfoundation.org/Development/Branches Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC][performance] report - week #4
Hi Matus, On Sun, 2011-06-19 at 23:30 +0200, Matúš Kukan wrote: I've started adding prefixes for components, so we can then merge libraries. Just in already gnumake-ified modules. Nice :-) First was toolkit. There is just one component and it seems to be working. I have tested that component. Great. Then some components in configmgr, vcl, comphelper, sfx2, framework, svtools, svl. It's not straightforward always. For example in sfx2 there were also component_ methods in workben directory. I've ignored them. What's in workben directories? workben/ directories are random bits of test code that might be useful someday, and/or are used by developers in the know to test things; we're trying to deprecated them in favour of always-run, at-compile, in-tree unit tests. Now I'm playing with makefiles and next week I want to merge some libraries. Heh - hopefully we can identify which libraries to merge there; then I guess we will need to come up with a strategy for doing that cleanly - particularly each dependent library binary will need re-linking and their Makefile's updating to reflect that I suppose. So - we should do it with a couple of libraries first, and only after some consensus is reached on how to do that - you're researching which ones are best to merge now I think ? :-) Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
On Mon, Jun 20, 2011 at 5:31 AM, Caolán McNamara caol...@redhat.com wrote: On Mon, 2011-06-20 at 09:51 +0530, Marc-André Laverdière wrote: Hello list. Now, I think we should make it multi-platform, so that the whole code base can benefit from it. The transition must be gradual, for sure, but I think we'd benefit a lot from it in the long run. I have to say, I'm kind of unenthusiastic about deprecating strlen and memcpy. Same here. There are plenty of legitimate safe use of these functions, including in performance critical sections. Beside the so-called 'safe' memcpy, for example, is only 'safe' if it is being audited anyway against abuse ( memcpy(d,s,count) - memcpy_s(d, count, s, count)) so the _s create a false sens of security... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
so the _s create a false sens of security... Exactly. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [REVIEWED][PUSHED:master; 3.4; 3-4-1] fix fdo#37110 --quickstart shouldn't show start center
Michael Meeks píše v Po 20. 06. 2011 v 12:03 +0100: On Mon, 2011-06-20 at 02:26 -0600, Tor Lillqvist wrote: Go ahead and push to master and 3-4. Two more reviews needed for 3-4-1, unless it is already too late for that. bug: https://bugs.freedesktop.org/show_bug.cgi?id=37110 patch: https://bugs.freedesktop.org/attachment.cgi?id=48149 Looks good to me; I assume we need one more approval to get it into 3.4.1. Look fine. This is 3rd approval = pushed into libreoffice-3-4-1 branch. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Making our Own Banned.h
On Mon, Jun 20, 2011 at 4:14 PM, Tor Lillqvist tlillqv...@novell.com wrote: so the _s create a false sens of security... On the other hand, I guess shouldn't be that bad to use the secure functions on the Windows specific bits of code. If I remember well, Mingw32 ships the safelib too, so it wouldn't be a problem for crosscompilation. Any advantages of doing that? Well, we could issue a nice PR saying that the Windows code is now more secure :P -- Jesús Corrius je...@softcatala.org Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] add newlines to EOF where missing to avoid compile time warnings
Hi I got fed up by the warnings while compiling. Okay to commit? diff --git a/sc/source/core/data/documen8.cxx b/sc/source/core/data/documen8.cxx index 23cb408..90fdf5c 100644 --- a/sc/source/core/data/documen8.cxx +++ b/sc/source/core/data/documen8.cxx @@ -1621,4 +1621,4 @@ void ScDocument::TransliterateText( const ScMarkData rMultiMark, sal_Int32 nTyp delete pEngine; } -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/package/source/zipapi/sha1context.hxx b/package/source/zipapi/sha1context.hxx index c8f6068..6d9374d 100644 --- a/package/source/zipapi/sha1context.hxx +++ b/package/source/zipapi/sha1context.hxx @@ -56,4 +56,4 @@ public: #endif -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/svtools/inc/svtools/grfmgr.hxx b/svtools/inc/svtools/grfmgr.hxx index 40602b8..a45b05b 100644 --- a/svtools/inc/svtools/grfmgr.hxx +++ b/svtools/inc/svtools/grfmgr.hxx @@ -574,4 +574,4 @@ public: #endif // _GRFMGR_HXX -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/svtools/source/filter/exportdialog.cxx b/svtools/source/filter/exportdialog.cxx index be9037c..eaf86cb 100644 --- a/svtools/source/filter/exportdialog.cxx +++ b/svtools/source/filter/exportdialog.cxx @@ -1512,4 +1512,4 @@ IMPL_LINK( ExportDialog, OK, void *, EMPTYARG ) return 0; } -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/svtools/source/filter/filter2.cxx b/svtools/source/filter/filter2.cxx index cd89c2f..5a42b8b 100644 --- a/svtools/source/filter/filter2.cxx +++ b/svtools/source/filter/filter2.cxx @@ -1352,4 +1352,4 @@ String GraphicDescriptor::GetImportFormatShortName( sal_uInt16 nFormat ) return String( aKeyName, RTL_TEXTENCODING_ASCII_US ); } -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/svtools/source/graphic/grfmgr.cxx b/svtools/source/graphic/grfmgr.cxx index 09127c0..15de989 100644 --- a/svtools/source/graphic/grfmgr.cxx +++ b/svtools/source/graphic/grfmgr.cxx @@ -1232,4 +1232,4 @@ GraphicObject GraphicObject::CreateGraphicObjectFromURL( const ::rtl::OUString } } -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/svtools/source/graphic/grfmgr2.cxx b/svtools/source/graphic/grfmgr2.cxx index 320435a..d1a6205 100644 --- a/svtools/source/graphic/grfmgr2.cxx +++ b/svtools/source/graphic/grfmgr2.cxx @@ -2384,4 +2384,4 @@ void GraphicObject::ImplTransformBitmap( BitmapEx rBmpEx, } } -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/vcl/inc/vcl/gdimtf.hxx b/vcl/inc/vcl/gdimtf.hxx index 87eecfb..0320802 100644 --- a/vcl/inc/vcl/gdimtf.hxx +++ b/vcl/inc/vcl/gdimtf.hxx @@ -291,4 +291,4 @@ MetaCommentAction* makePluggableRendererAction( const rtl::OUString rRendererSe #endif // _SV_GDIMTF_HXX -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/vcl/inc/vcl/graph.hxx b/vcl/inc/vcl/graph.hxx index bffd8e6..c8b7516 100644 --- a/vcl/inc/vcl/graph.hxx +++ b/vcl/inc/vcl/graph.hxx @@ -222,4 +222,4 @@ public: #endif // _SV_GRAPH_HXX -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/vcl/inc/vcl/svgread.hxx b/vcl/inc/vcl/svgread.hxx index 4427198..cf4f800 100644 --- a/vcl/inc/vcl/svgread.hxx +++ b/vcl/inc/vcl/svgread.hxx @@ -80,4 +80,4 @@ namespace vcl #endif -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/vcl/source/gdi/metaact.cxx b/vcl/source/gdi/metaact.cxx index 1e94535..a2268ab 100644 --- a/vcl/source/gdi/metaact.cxx +++ b/vcl/source/gdi/metaact.cxx @@ -4409,4 +4409,4 @@ void MetaRenderGraphicAction::Read( SvStream rIStm, ImplMetaReadData* ) rIStm maRenderGraphic maPoint maSize mfRotateAngle mfShearAngleX mfShearAngleY; } -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline at end of file +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ diff --git a/sw/source/ui/shells/grfsh.cxx b/sw/source/ui/shells/grfsh.cxx index 30c7fe0..739bd4c 100644 --- a/sw/source/ui/shells/grfsh.cxx +++ b/sw/source/ui/shells/grfsh.cxx @@ -703,4 +703,4 @@ SwGrfShell::SwGrfShell(SwView _rView) : SetHelpId(SW_GRFSHELL); } -/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ \ No newline
Re: [Libreoffice] [PATCH] Additional fix for bug fdo#33781
Hi Ronald,
Roland Baudin píše v Pá 17. 06. 2011 v 23:23 +0200:
Hi,
here is a small patch for sw that fixes another issue related to bug
33781 that I already fixed last month.
The problem is that a graphic object of type Draw 8 is not
anti-aliased when anchored as char (see test file for example).
IMHO, this patch is safe and acts exactly the same as the previous fix
for bug 33781.
It works nice.
Well, just after your new lines there is another hack with aliasing for
http://openoffice.org/bugzilla/show_bug.cgi?id=99665 . It solves the
problem where the aliasing caused problems = we should be more careful
with setting aliasing to ANTIALIASING_ENABLE_B2DDRAW globally.
I prefer the more conservative approach from i#99665. It modifies the
current aliasing using byte or (operator |) and restores the original
aliasing at the end of the if block.
I see that the aliasing value is always modified by byte operators '',
'|'. Try to search for ANTIALIASING_ENABLE_B2DDRAW at
http://opengrok.libreoffice.org/
So, what do you think about the attached patch?
It uses the conservative approach from i#99665 also for your two
changes. Also it combines your fix with the fix for i#99665 to avoid two
nFormerAntialiasingAtOutput variables.
I would prefer to sort this out before we cherry-pick it to
libreoffice-3-4 branch.
Best Regards,
Petr
--- sw/source/core/doc/notxtfrm.cxx.old1 2011-06-20 17:00:58.0 +0200
+++ sw/source/core/doc/notxtfrm.cxx 2011-06-20 17:24:18.0 +0200
@@ -819,9 +819,10 @@ void SwNoTxtFrm::PaintPicture( OutputDev
if( pGrfNd )
{
// Fix for bug fdo#33781
+const sal_uInt16 nFormerAntialiasingAtOutput( pOut-GetAntialiasing() );
if (pShell-Imp()-GetDrawView()-IsAntiAliasing())
{
-pOut-SetAntialiasing( ANTIALIASING_ENABLE_B2DDRAW );
+pOut-SetAntialiasing( nFormerAntialiasingAtOutput | ANTIALIASING_ENABLE_B2DDRAW );
}
sal_Bool bForceSwap = sal_False, bContinue = sal_True;
@@ -938,8 +939,12 @@ void SwNoTxtFrm::PaintPicture( OutputDev
if( bSwapped bPrn )
bForceSwap = sal_True;
}
+
if( bForceSwap )
pGrfNd-SwapOut();
+
+if ( pShell-Imp()-GetDrawView()-IsAntiAliasing() )
+pOut-SetAntialiasing( nFormerAntialiasingAtOutput );
}
else if( bIsChart
//charts must be painted resolution dependent!! #i82893#, #i75867#
@@ -953,22 +958,18 @@ void SwNoTxtFrm::PaintPicture( OutputDev
else if( pOLENd )
{
// Fix for bug fdo#33781
+const sal_uInt16 nFormerAntialiasingAtOutput( pOut-GetAntialiasing() );
if (pShell-Imp()-GetDrawView()-IsAntiAliasing())
{
-pOut-SetAntialiasing( ANTIALIASING_ENABLE_B2DDRAW );
-}
+sal_uInt16 nNewAntialiasingAtOutput = nFormerAntialiasingAtOutput | ANTIALIASING_ENABLE_B2DDRAW;
-// #i99665#
-// Adjust AntiAliasing mode at output device for chart OLE
-const sal_uInt16 nFormerAntialiasingAtOutput( pOut-GetAntialiasing() );
-if ( pOLENd-IsChart()
- pShell-Imp()-GetDrawView()-IsAntiAliasing() )
-{
-const sal_uInt16 nAntialiasingForChartOLE =
-nFormerAntialiasingAtOutput | ANTIALIASING_PIXELSNAPHAIRLINE;
-pOut-SetAntialiasing( nAntialiasingForChartOLE );
+// #i99665#
+// Adjust AntiAliasing mode at output device for chart OLE
+if ( pOLENd-IsChart() )
+nNewAntialiasingAtOutput |= ANTIALIASING_PIXELSNAPHAIRLINE;
+
+pOut-SetAntialiasing( nNewAntialiasingAtOutput );
}
-// --
Point aPosition(aAlignedGrfArea.Pos());
Size aSize(aAlignedGrfArea.SSize());
@@ -1012,13 +1013,8 @@ void SwNoTxtFrm::PaintPicture( OutputDev
((SwFEShell*)pShell)-ConnectObj( pOLENd-GetOLEObj().GetObject(), pFly-Prt(), pFly-Frm());
}
-// #i99665#
-if ( pOLENd-IsChart()
- pShell-Imp()-GetDrawView()-IsAntiAliasing() )
-{
+if ( pShell-Imp()-GetDrawView()-IsAntiAliasing() )
pOut-SetAntialiasing( nFormerAntialiasingAtOutput );
-}
-// --
}
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Interesting difference in thread-specific data function semantics for Windows vs. Unix
On Mon, 2011-06-20 at 13:50 +0100, Caolán McNamara wrote: If we want c), which is a more attractive and obvious api, then the attached would do it I think. I decided to push c, hopefully that resolves this correctly. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC][performance] report - week #4
Hi Michael, On 20 June 2011 16:02, Michael Meeks michael.me...@novell.com wrote: On Sun, 2011-06-19 at 23:30 +0200, Matúš Kukan wrote: Now I'm playing with makefiles and next week I want to merge some libraries. Heh - hopefully we can identify which libraries to merge there; then I guess we will need to come up with a strategy for doing that cleanly - particularly each dependent library binary will need re-linking and their Makefile's updating to reflect that I suppose. So, I was thinking if it is possible just to do some magic like 'merge libX.so libY.so libXY.so' and tell components X and Y to use libXY.so. But probably not or it's not clean solution. So we will stop creating lib(X|Y).so and in some Makefile just create one library from all the source files? And what if they are from different modules? So - we should do it with a couple of libraries first, and only after some consensus is reached on how to do that - you're researching which ones are best to merge now I think ? :-) I'm sending list of libraries together with modules they belong to. Maybe I could try to merge framework ones? fwe and fwi shouldn't belong to UNO component. Just fwk, fwl, fwm. But only fwk is used 5 times. Matus libraries Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Couldn't debug fdo#30550 (WAS: Build failed in sfx2 in -3-3 branch)
Hello Petr, Michael, * Many thanks for your answer :) My build was success with --disable-systray Anyway, may I ask some questions please? On Fri, Jun 17, 2011 at 18:08, Petr Mladek pmla...@suse.cz wrote: This header should be provided by the module libegg. Please, make sure that this module is built and delivered. On Fri, Jun 17, 2011 at 19:40, Michael Meeks michael.me...@novell.com wrote: Do you have a libegg/ directory in clone/libs-extern/ ? Possibly your clone / download / unpack script failed mid-flow ? How do I know that libegg module is built and delivered? And yes, my clone/libs-extern/libegg does exists. Just for a reminder: I was trying to fix fdo#30550: wordcount without space counted incorrectly Next, I was trying to use gdb debug by following [1], but it wasn't success. This was my trying: I ./autogen.sh with --enable-symbols[1], make, make dev-install, build debug=true in sw[2], then run swriter After attaching soffice.bin to gdb using gdb soffice.bin $LOPID[1] libo writer was paused (which is normal, isn't it?) Notice: there're many shouts from gdb at me after attached, like Reading symbol from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libk5crypto.so.3 etc. So, if libo was paused, how could I select a word and click Tools Word Count? I've tried to set breakpoints in 3 functions named CountWords[3], but it failed. The point is I can't click anything while it's paused. If I typed 'continue' (while libo paused) in gdb, it released. (expected) Then I select some text and click Tools Word Count, but it didn't pause or break (in any breakpoints), and I can't get libo paused again. Did I walk through a right way? And sorry if any of my questions or above procedure seem stupid. [1] http://wiki.documentfoundation.org/Development/How_to_debug [2] http://wiki.documentfoundation.org/Development/Native_Build#Partial_debug_build [3] The three are: SwEditShell::CountWords, SwDoc::CountWords, and SwTxtNode::CountWords, as found from (gdb) 'info fun CountWords' Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Interesting difference in thread-specific data function semantics for Windows vs. Unix
On Mon, 2011-06-20 at 13:50 +0100, Caolán McNamara wrote: If we want c), which is a more attractive and obvious api, then the attached would do it I think. It does mean a change of the typedef of oslThreadKey from sal_uInt32 to void*, which changes its size on 64bit. So technically this is an incompatible change for 64bit binary extensions that use this obscure api. As you say - this seems to be the right way to do it :-) Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Help fixing ImplHandleInputLangChange implementation
Hi all,
I'd like to fix this function implementation, as it makes my eyes cry ;)
Notice that if pFrame == NULL, the function will crash anyway because
it's only checked in the first if block and later is dereferenced.
static void ImplHandleInputLangChange( HWND hWnd, WPARAM, LPARAM lParam )
{
ImplSalYieldMutexAcquireWithWait();
// Feststellen, ob wir IME unterstuetzen
WinSalFrame* pFrame = GetWindowPtr( hWnd );
if ( pFrame pFrame-mbIME pFrame-mhDefIMEContext )
{
HKL hKL = (HKL)lParam;
UINTnImeProps = ImmGetProperty( hKL, IGP_PROPERTY );
pFrame-mbSpezIME = (nImeProps IME_PROP_SPECIAL_UI) != 0;
pFrame-mbAtCursorIME = (nImeProps IME_PROP_AT_CARET) != 0;
pFrame-mbHandleIME = !pFrame-mbSpezIME;
}
// trigger input language and codepage update
UINT nLang = pFrame-mnInputLang;
ImplUpdateInputLang( pFrame );
// notify change
if( nLang != pFrame-mnInputLang )
pFrame-CallCallback( SALEVENT_INPUTLANGUAGECHANGE, 0 );
ImplSalYieldMutexRelease();
}
What's the preferred way to fix it?
a) put everything in an if (pFrame) {} block
b) if(!pFrame) return;
Thanks for the help! :)
--
Jesús Corrius je...@softcatala.org
Document Foundation founding member
Mobile: +34 661 11 38 26
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] patch for fdo#38455
Hello, I have here a quick patch for fdo#38455. Calc crahs if you go to Data-Define range and type some text to a cell because pActiveViewSh isn't set in the InputHandler. http://cgit.freedesktop.org/libreoffice/calc/commit/?id=165ccab687d976d06afa0b02582065045132ee6d This fix only checks that pActiveViewSh is not null. I might come up with a better patch if I change my mind and think that pActiveViewSh should not be null there. But at least this patch fixes the crash at the moment. I'd like to get this patch into 3-4 and if still possible into 3-4-1. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] patch for fdo#38455
Hi Markus, On Mon, 2011-06-20 at 21:04 +0200, Markus Mohrhard wrote: I have here a quick patch for fdo#38455. Calc crahs if you go to Data-Define range and type some text to a cell because pActiveViewSh isn't set in the InputHandler. Hokay ? This fix only checks that pActiveViewSh is not null. I might come up with a better patch if I change my mind and think that pActiveViewSh should not be null there. But at least this patch fixes the crash at the moment. The rest of that method seems to assume in several places that pActiveViewSh can be NULL and checks for that: if (pActiveViewSh) pActiveViewSh-GetViewData()-GetDocShell()-PostEditView( pEngine, aCurso... Window* pFrameWin = pActiveViewSh ? pActiveViewSh-GetFrameWin() : NULL etc. which makes me wonder if this is really the fix ? are we perhaps missing a more granular check ? Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Help fixing ImplHandleInputLangChange implementation
Hi Jesus,
On Mon, 2011-06-20 at 20:47 +0200, Jesús Corrius wrote:
What's the preferred way to fix it?
:-)
a) put everything in an if (pFrame) {} block
b) if(!pFrame) return;
It can help debugging if methods always return from the same place; but
then it can help code readability if it is not incredibly deeply
indented.
Thanks for the help! :)
Sorry for not helping :-) just do what you think fits best with that
module's practise and style.
Thanks !
Michael.;
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Le 20/06/2011 15:19, Caolán McNamara a écrit :
On Mon, 2011-06-20 at 10:08 +0100, serv serva wrote:
It happens each time. I don't know what element has triggered this.
I tried gdb but when I runned it, it makes the first which is ok. I don't know
how to go to this specific test.
Could you see the patch in the other thread interesting difference
in... and see if it makes a difference to this problem as well.
C.
Hello,
I just git updated and read that you had commited and pushed your patch.
So I did a rm -rf unxlng* in sal and build again.
I've still got an error but it's slightly different, here is what I get :
Making:libosl_process.so
Making:all_qa_osl_process.dpslo
--
- start unit test #1 on library ../../../unxlngi6/lib/libosl_Thread.so
--
:
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_Thread.so
OK (6)
--
- start unit test #2 on library ../../../unxlngi6/lib/libosl_process.so
--
:
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_process.so
*** glibc detected *** ../../../unxlngi6/bin/cppunittester: free():
invalid pointer: 0xb74facd0Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
/bin/bash: line 1: 15149 Aborted
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_process.so
dmake: Error code 134, while making 'test2'
We clearly see in the logs that there's an invalid pointer.
Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] patch for fdo#38455
On Mon, 2011-06-20 at 20:25 +0100, Michael Meeks wrote: The rest of that method seems to assume in several places that pActiveViewSh can be NULL and checks for that: Markus is committing an updated patch to master, that I'd love to see on -3-4 and also in -3-4-1 it potentially fixes another as-yet-un-found crasher too. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Help fixing ImplHandleInputLangChange implementation
It can help debugging if methods always return from the same place; but then it can help code readability if it is not incredibly deeply indented. I am from the code readability school of programing :) Thanks for the help! :) Sorry for not helping :-) just do what you think fits best with that module's practise and style. The problem is that there's no consistency at all in that module and it's done both ways without much sense :) I guess the Windows vcl code is a good candidate for a good code review... -- Jesús Corrius je...@softcatala.org Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Proposta COLORATUS Design
Title: Coloratus Design Não conseguiu visualizar a mensagem? Click aqui Não gostaria mais de receber nossos emails? Remova-se aqui www.coloratusdesign.com Organize-se na internet! A internet hoje e o maior meio de comunicação usando pelas pessoas de todo Brasil. Pela internet fazemos compras, procuramos serviços participamos de redes sociais, etc. Você ainda não obteve seu website assustado com os valores cobrados e a falta de eficácia atualmente, ou teme solicitar um orçamento e obter sempre o mesmo resultado. Assim a Coloratus Design encaixa-se na sua empresa oferecendo recursos web inovadores e opção para a sua empresa. Atualmente oferecemos vários planos para todas plataformas, planos de websites completos com ainda desenvolvimento personalizado e hospedagem inclusa por apenas 29,90. Web-marketing a nova tecnológia da mídia! Pensou em divulgar? Desenvolva uma campanha estratégia atingido seu público alvo e obtendo resultados imediatos. Oferecemos planos mensais e valores de campanhas únicas, confira. Ainda não têm seu próprio website? Não perca mais
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Rainer Bielefeld libreoff...@bielefeldundbuss.de changed: What|Removed |Added Depends on||37195 --- Comment #151 from Rainer Bielefeld libreoff...@bielefeldundbuss.de 2011-06-20 21:46:16 PDT --- Nominating Bug 37195 - Dictionary access lost after LibO upgrade. It's not acceptable that users have to edit the user profile folders to regain access to their dictionaries. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
